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!

Publicada la CTP de Enero de 2009 de Oslo

Último viernes de este mes, última tarea de la semana… CTP de Enero de Oslo disponible públicamente para descarga en el MSDN Oslo Developer Center!

Vale, lo cierto es que lleva ya unas horas “viva” y he sido yo quien ha dejado para el último momento del día este post… 🙂

Se trata de la segunda CTP de Oslo, tras la liberada durante el último PDC, a finales del mes de Octubre de 2008.

¿Qué novedades incluye esta CTP?

Fundamentalmente, unos cuantos bugfixes en base al feedback recibido durante estos tres meses. Además se han realizado algunas modificaciones e incrementos funcionales:

  • Mejoras para definir gramáticas con MGrammar que resultan mucho más intuitivas de cara al desarrollador. (Token Actions)
  • Nuevas construcciones sintácticas de MGraph soportadas a la hora de definir gramáticas para simplificar este proceso.
  • Métodos adicionales a la hora de trabajar con colecciones: Count, Choose, Distinct, All, Exists…

Herramientas incluídas en la CTP

  • SDK
    • Integración con Visual Studio 2008 para editar y generar artefactos con lenguaje M.
    • Intellipad: Un editor de texto bastante ligero y totalmente integrado con las funcionades que M nos ofrece (traducción a T-SQL, etc).
    • Compiladores para el lenguaje M.
    • Mx.exe: Utilidades para línea de comandos que nos permiten importar y exportar modelos a SQL Server 2008.
    • Add-in para Excel 2007: Nos permite visualizar en hojas de cálculo colecciones de tablas generadas con M.
  • Documentación:
    • Especificación formal del lenguaje M.
    • Glosario de primitivas del lenguaje M.
    • Documentación adicional de ayuda y referencia.
  • Ejemplos:
    • Gran cantidad de modelos creados con M.
    • Ejemplo para ilustrar la forma en que funciona el parser de M.
    • Escenario completo de integración de modelos desarrollados con M y SQL Server Integration Services.
    • Código fuente de los modelos creados con M mediante los cuales se modela propiamente Oslo.
  • Herramientas para trabajar con el repositorio:
    • CreateRepository.exe: Una herramienta que nos permite crear nuestro repositorio de modelos en SQL Server 2008.
    • Models.mx: Imagen compilada de los modelos utilizados para desarrollar Oslo.
    • Mx.mx: Imagen compilada con modelos adicionales para Mx.exe.

Para más información podéis consultar las Release Notes.

Próximamente nuevos posts con ejemplos, reflexiones y vídeos sobre Oslo!

Enjoy!!

MSDN Oslo Developer Center: Primeros contenidos en Español

Hoy ha sido publicado en el MSDN Oslo Developer Center el primer contenido en lengua castellana. Se trata de un artículo titulado “Oslo y el desarrollo basado en modelos” que escribí para el número de Diciembre de la revista dotNetMania. Podéis acceder al contenido a través del siguiente enlace: http://msdn.microsoft.com/es-es/library/dd367845.aspx

image

Próximamente habrá más (y mejores) contenidos en nuestra propia “DSL Española” en el Oslo Developer Center. 😉

Por último, me gustaría agradecer a la revista dotNetMania, personalizando en su editor Paco Marín y en su redactor jefe Marino Posadas, su colaboración para que este artículo haya podido ser incluído en MSDN. En general, a todos los profesionales que colaboran o han colaborado en la revista, enhorabuena por vuestro genial trabajo y excelente nivel de contenidos.

Happy Weekend!!

Datos o metadatos, esa es la cuestión

En un post anterior acerca del lenguaje M, se planteó una duda en los comentarios acerca de qué relación guarda M con las tecnologías ORM, empleadas para el mapeado de datos de tipo relacional. Lo cierto es que el lenguaje M cubre una gran cantidad de necesidades diferentes (tanto en cuanto es modular y cada módulo ya desarrollado aborda diferentes problemas) y proporciona una serie de herramientas que posibilitan la creación de nuevos lenguajes específicos de dominio (DSL) que permiten describir modelos. Si bien, no es en sí mismo una tecnología que vaya a reemplazar a ningún ORM empleado en la actualidad. Al menos no es esa la intención, ni tampoco será la tendencia más generalizada.

No obstante, considero interesante puntualizar algunos aspectos ya que a menudo cuando hablamos acerca de Oslo surge cierta confusión en el público. Esta confusión viene según mi percepción causada por dos motivos principales. El primero de ellos es el hecho de que Oslo esté diseñado en un nivel de abstracción superior al de la mayoría de sistemas actuales, por tanto su ámbito es muy amplio y tendrá un impacto importante en prácticamente cualquier producto de desarrollo de Microsoft… y sino al tiempo…  Podéis apostar sobre seguro acerca de esto último, yo ya lo he hecho. Debido a la propia amplitud y elevada abstracción de este concepto, resulta en ocasiones complejo percibirlo con exactitud.

El segundo motivo de confusión principal es consecuencia directa de esta naturaleza abstracta de Oslo. Cuando hablamos en Oslo acerca de determinados conceptos como lenguajes, modelos, repositorio, etc. estamos empleando términos que han sido definidos ya en multitud de ocasiones para niveles de abstracción inferiores. Hablando en términos OOP, al emplear este vocabulario hablando sobre Oslo estamos redefiniendo métodos de una clase base que ya han sido definidos durante años en las clases derivadas de ésta. En este sentido, mi recomendación es que tratéis de olvidar todo cuanto os han enseñado en este ámbito, ya que muchos de esos conceptos asimilados en el pasado están basados en una visión miope del espacio. No obstante, una vez nos hayamos familiarizado con la jerga de Oslo, percibiremos el uso de estos términos como algo natural, e incluso comprenderemos mejor su significado para dominios más concretos.

Otro de los comentarios en dicha entrada hacía referencia al hecho de que Oslo «no es para nada algo nuevo«. Bien, en este sentido, argumentaré que de hecho Oslo no es algo completamente nuevo. Es más, me compadezco de cualquier presunto avance tecnológico que sea totalmente nuevo. Obviar tecnologías previas y aproximaciones a problemas ya propuestas es uno de los mayores defectos en Ingeniería, puesto que limita la capacidad de análisis en la validez de nuestra propia solución. Más allá de esta consideración, lo cierto es que Oslo toma prestadas muchas ideas sobre herramientas previas en el campo del desarrollo dirigido por modelos (MDD) y a dichas ideas añadimos un plus de funcionalidad y una vuelta de tuerca, basada en años de investigación propia y, por supuesto, influenciada por la comunidad investigadora en el ámbito MDD. Oslo trata de dar un enfoque coherente con las tecnologías y herramientas actuales y una visión evolucionada sobre el desarrollo de software, combinando partes muy diversas que han estado tradicionalmente desconectadas y que además entrañan una serie de dificultades de conexión, la combinación efectiva de todas estas piezas proporciona «un todo» mucho más potente, eficiente y adaptativo, aplicable a cualquier tipo de entorno de desarrollo. Sobre esto último me he propuesto convenceros en los próximos meses y años, así que prepararos para ver muchas, muchísimas, entradas al respecto de este tema. 😛

Tras esta introducción al contexto del post, ahí va mi pequeña historieta. Espero que sea en cierto grado explicativa.

A menudo vienen a mi cabeza recuerdos de mis primeros años de carrera. En realidad, no ha pasado demasiado tiempo desde eso, e incluso se podría decir que casi fue ayer cuando comencé en 1º de Informática (allá por el año 2002). Tras unos cuantos años en las aulas y muchas más horas de aprendizaje autodidacta y momentos excepcionales en la cafetería, vuelvo a plantearme algunas de esas preguntas, debates y conceptos un tanto dogmáticos que en aquellos primeros maravillosos años me hicieron asumir.

Uno de estos dogmas gira en torno a la diferencia entre datos y metadatos. Generalmente, a la hora de abordar esta cuestión, solemos encontrarnos con dos tipos diferentes de respuestas, o dos enfoques diferentes para una misma respuesta: «existe una gran diferencia entre datos y metadatos». En mi modesta opinión, uno de los enfoques es ambiguo, y el otro es erróneo.

El primero de estos enfoques hace referencia al tipo de información contenida por nuestros datos y por nuestros metadatos. Tradicionalmente, podemos definir el término «datos» como «conjunto de información [estructurada]» y «metadatos» como «datos que contienen información sobre otros datos». Hasta aquí, imagino que todos estaremos de acuerdo. Ahora bien, esta definición es bastante ambigua puesto que, en muchas ocasiones, una misma información puede ser dato o metadato en función del enfoque que estemos empleando. Por ejemplo, si estamos manejando información sobre películas, el título de una película es un dato; no obstante, dicho título (probablemente) aporte información acerca del argumento o tipo de película en cuestión. Por tanto, en este caso el título de dicha película podría considerarse al mismo tiempo un metadato. Como vemos, la frontera conceptual no está muy clara en esta primera aproximación.

La segunda aproximación de la respuesta pasa por considerar la frecuencia con la que empleamos estos datos. Esta aproximación está muy extendida y parte de la premisa de asociar los conceptos de «datos» y «datos transaccionales», tratándose de datos que utilizamos continuamente, en contraste con los metadatos que consultamos con bastante menor frecuencia. Adicionalmente, se suele asociar el concepto de metadatos con datos de sólo lectura, mientras que los datos transaccionales son aquellos que modificamos a menudo. Esta respuesta va incluso más allá, afirmando que esta diferencia no es tan sólo evidente, sino que además determina de qué forma deberemos acceder a nuestros datos y metadatos: «Los conjuntos de metadatos se rigen por patrones de acceso diferentes», he escuchado decir en alguna ocasión… Personalmente, y perdonadme por la expresión, esto me parece una auténtica chorrada. No podemos clasificar datos en función de su uso, en lugar de hacerlo propiamente por el tipo de éstos. Ya que, incluso en el hipotético caso de que asumiéramos este método como válido, estaríamos incurriendo nuevamente en una grave relajación de la frontera conceptual de ambos términos. Por ejemplo, consideremos una factura detallando el coste de una serie de materiales empleados para la construcción de un coche. Para el Ingeniero, la factura es un dato de tipo transaccional. No obstante, para el gestor de recursos, el coste de cada material es un metadato «de sólo lectura» que deberá considerar a la hora de realizar nuevos pedidos o diseñar el plan de producción.

Como podemos ver, ninguna de ambas aproximaciones es suficientemente esclarecedora, lo cual puede inducir a malentendidos graves en caso de asumir alguna de ellas. En mi opinión, el principal problema surge de la creencia de que existe la necesidad de clasificar diferentes tipos de datos, cuando realmente lo que existe es la necesidad de comprender cuándo y cómo emplear uno u otro. Me gustaría ir más lejos en este razonamiento y argumentar que, hablando en términos de almacenamiento y consulta de datos, serialización y transferencia de los mismos, así como el resto de cuestiones que realmente importan en el desarrollo de software de tipo empresarial, todos los datos son datos al fin y al cabo (valga la redundancia), y por ello no existe motivo realmente justificable para tratarlos de diferente forma desde el punto de vista de la arquitectura de nuestro sistema. De este modo, es probable que tengamos modelos primarios y modelos secundarios, modelos protegidos y modelos compartidos, pero al fin y al cabo todos ellos son modelos cuya finalidad es representar el comportamiento de nuestro software, y por supuesto la forma de acceder a ellos e incluso de modificarlos es exactamente idéntica. Tan sólo encontraremos diferencias en el propósito último de este proceso (finalidad con que consultamos dichos datos), pero no en su metodología.

En este sentido, en el equipo de Oslo nos hemos preocupado por ofrecer un amplio conjunto de herramientas que proporcionan capacidad más que suficiente a nuestros usuarios para (por este orden) describir una serie de datos o información, validar dichos datos, poder modificarlos, almacenarlos en un repositorio «in the cloud», y a través de dicho repositorio ser capaz de acceder nuevamente a ellos y también compartirlos. Los escenarios fundamentales en que contemplamos el uso de Oslo ahora mismo consisten en la definición de modelos y datos que describan los entornos de ejecución (runtimes) en los que ejecutar nuestro software. Sin embargo, este escenario no es el único en el que veremos presencia de Oslo con el paso del tiempo ya que, por una parte, las ambiciones del proyecto involucran además otra serie de escenarios y, por otra parte, la arquitectura y diseño del sistema permite la extensibilidad de este concepto.

De todo esto y más os hablaré en próximas entradas.  

El comité de inauguración de la Presidencia de Obama será retransmitido a través de Silverlight

Para todos aquellos interesados en seguir la ceremonia de inauguración de la presidencia de los EEUU de Barack Obama, el evento será retransmitido el martes 20 de Enero a través de la web oficial «Presidential Inaugural Commitee». La nota técnica de esta noticia radica en el hecho de que la tecnología de streaming de vídeo empleada para retransmitir el evento no es otra que Silverlight 2.0, podéis encontrar más información en el siguiente enlace.

De esta forma, el evento se unirá a la lista de «grandes eventos» a nivel mundial que se han podido seguir online mediante Silverlight, en cuya lista destacan también los JJOO de Beijing celebrados el pasado mes de Agosto.

Yes we can!

Software Engineering Radio [Episodio 123]: Microsoft OSLO con Don Box y Doug Purdy

En el último episodio de Software Engineering Radio, Don Box y Douglas Purdy (quienes llevan trabajando en este proyecto desde sus inicios, allá por el año 2005) ofrecen una visión general acerca de la plataforma y posteriormente hablan de la relación entre Oslo y otros enfoques en el ámbito de DSL/Model-Driven como DSL Tools, sobre los diferentes módulos que componen M, y algunas formas en que Oslo podría dotar de valor añadido a las tecnologías MD existentes en la actualidad. Pinchad en el banner para acceder al podcast.

Enjoy!

Los 25 errores de programación más peligrosos

Hace un par de días me encontré por la web con un interesante documento de investigación en el cual se enumeraban los 25 tipos de errores con un mayor riesgo potencial de provocar vulnerabilidades en nuestro software.

El documento se puede encontrar directamente aquí y contiene descripciones bastante apropiadas sobre diferentes vulnerabilidades «clásicas» como por ejemplo SQL injection, cross-site scripting, OS injection, validación de la entrada de nuestros programas… así como otras no demasiado obvias a priori. También contiene tácticas de prevención para cada una de ellas, desde el punto de vista arquitectural y de diseño, y también en cuanto a implementación.

Espero que disfrutéis con su lectura tanto como he disfrutado yo (sé que puede sonar mal, pero estos errores vistos en código ajeno pueden resultar hasta divertidos, jeje), y en cualquier caso es una buena fuente resumida a la que acudir en caso de emergencia…

Un saludo.

Primer post de 2009: Top 10 de eWeek de productos para el desarrollo de aplicaciones en 2008

¡Feliz año nuevo a todos! Con un día de retraso sobre mi calendario previsto (debido a mis queridos amiguetes de Iberia) vuelvo a retomar el blog con las pilas cargadas y dispuesto a contaros muchas cosas acerca de tecnologías Microsoft en general, del desarrollo basado en la nube en particular y de Oslo en concreto.


Puesto que el 2008 ha sido un año cargado de novedades a nivel tecnológico, creo que es de recibo echar un vistazo a algunas de ellas, y qué mejor forma de hacerlo que repasando la lista Top 10 de eWeek, donde enumeran las 10 tecnologías a su juicio más relevantes para el desarrollo de aplicaciones que han aparecido en 2008. Son éstas:



  1. Windows Azure: Qué decir sobre Azure que no hayáis escuchado/leído ya… El primer sistema operativo de Microsoft basado en la nube, y orientado al desarrollo empleando «building-block» services vio la luz en el pasado PDC 2008, en el mes de Octubre. Se trata de uno de los pilares de la denominada «Cloud Strategy» en la cual, desde su llegada como Software Architect a Microsoft, ha puesto gran parte de sus esfuerzos Ray Ozzie.

  2. Google App Engine: Encontramos en el segundo puesto de esta lista la nueva tecnología de Google que permite albergar nuestras aplicaciones web en servidores de Google, facilitando de esta forma la escalabilidad de las mismas.

  3. Amazon CloudFront: El nuevo servicio web de Amazon para la integración de contenido distribuido ocupa una meritoria tercera posición en la lista.

  4. Flash 10: La nueva versión de este viejo conocido de todos nosotros incorpora mejoras en el nivel de expresidad de la API para la creación de formas geométricas, mejoras de rendimiento en contenidos y efectos 3D, entre otras novedades. Este hecho les ha valido para alcanzar la 4ª posición de la lista.

  5. JavaFX: Primera aproximación de Sun al mundo de las RIA, calificada por el propio CEO de Sun, Jonathan Schwartz, como «una de las tecnologías más importantes que veremos por parte de Sun en un futuro próximo y medio».

  6. Adobe «Thermo» (Adobe Flash Catalyst): Herramienta para diseñadores de Flash que les permite «convertir» sus diseños en aplicaciones sin la necesidad de escribir código fuente.

  7. Silverlight 2: El puesto número 7 de la lista corresponde a la segunda versión de Silverlight, la apuesta de Microsoft para el desarrollo de RIA y gestión de contenidos multimedia en Internet.

  8. Spring DM Server: Servidor de aplicaciones Java basado en OSGi, de tipo modular, desarrollado por la empresa SpringSource.

  9. Microsoft Oslo: Primera oleada de tecnologías que constituirán la plataforma de modelado software de Microsoft, está compuesta por tres elementos fundamentales: un lenguaje textual de modelado (lenguaje M), una herramienta visual de modelado (Quadrant) y un repositorio relacional de modelos (sobre SQL Server 2008, pero extendible a cualquier origen de datos como veremos en próximos posts).

  10. Apple iPhone SDK: Cierra la lista esta SDK de Apple, que permite desarrollar aplicaciones para iPhone e iPod Touch y también incluye un simulador de iPhone para poder probarlas.

Una vez repasada la lista, mis conclusiones… Creo que la lista es un fiel reflejo de la tendencia que en 2007 y especialmente en 2008 hemos podido observar hacia la nube. Si hacemos un recuento de estas 10 tecnologías, 3 de ellas permiten alojar en la nube nuestras aplicaciones, otras 4 son tecnologías (o herramientas) para el desarrollo de aplicaciones RIA, otra permite la integración de contenidos distribuidos mediante el uso de un WS, y por últimos encontramos la SDK de iPhone como representante del desarrollo para dispositivos móviles (si existe un complemento intrínseco del concepto de nube, es la ubicuidad que el uso de diferentes dispositivos nos proporciona) y también Oslo, parcialmente relacionado con tecnologías cloud, por el uso de un repositorio en la nube para compartir y reutilizar modelos.


Desde otra perspectiva, vemos que la compañía con mayor presencia en la lista es Microsoft (3), seguida de Adobe (2) y de Google, Amazon, Sun, SpringSource y Apple (todas ellas con 1). Hecho en falta, sin embargo, la presencia de Live Mesh y su API de desarrollo en esta lista, por citar un caso concreto.


Por último, «nos llena de orgullo y satisfacción» el hecho de que Oslo aparezca en este selecto grupo, teniendo en cuenta que apenas os hemos mostrado gran cosa por el momento, más allá de una primera CTP, unas cuantas charlas y artículos, etc. Aún así, confío en que se trate de un buen adelanto de lo que el 2009 nos deparará en torno a Oslo… Como bien dijo el gran filósofo chino Lao-Tsé: «Un viaje de mil millas comienza con el primer paso»


Al mismo tiempo, aprovecho para agradecer el feedback y comentarios que muchos de vosotros me estáis enviando, es realmente útil y me ayuda a «modelar» el mensaje/s acerca de Oslo, ¡gracias!