Primeros pasos con el lenguaje M (Capítulo 1)

En mi último post adelanté algunos aspectos sobre la definición de tipos y gramáticas mediante el uso del lenguaje de modelado M, con el fin de aclarar una duda concreta. No obstante, creo que este post resultará útil a modo de introducción al lenguaje y también como recopilación de enlaces a contenidos interesantes.


En primer lugar, destacar que el lenguaje M es el lenguaje de modelado para Oslo. De hecho, el origen del nombre no es la M de Miguel, sino la M de Modelo. Este lenguaje nos va a permitir llevar a cabo dos tipos de tareas: construir modelos e interactuar con datos. En esta segunda tarea, una de las grandes ventajas del lenguaje M es que se trata de un lenguaje independiente de plataforma. M se centra en proporcionar una serie de construcciones semánticas para definir qué estructuras deben dar forma a nuestros datos, pero abstrae completamente los elementos específicos a cada fuente de datos para llevarlo a cabo.


De forma resumida, podríamos decir que el lenguaje M se fundamenta en tres conceptos:



  • Valores: Un valor es un dato que cumple con las reglas y restricciones del lenguaje. Para cualquier sistema o aplicación, existen multitud de valores y relaciones entre ellos, también restricciones. Cuando diseñamos/modelamos un sistema, en esencia estamos definiendo qué tipos de valores podemos encontrar, cómo se relacionan entre ellos y qué restricciones condicionan su comportamiento. Podemos clasificar los valores en lenguaje M en tres categorías fundamentales:

    • Simples o escalares: Valores atómicos (no pueden descomponerse en valores más simples). En esta categoría encontramos los tipos intrínsecos del lenguaje (más adelante hablaremos de ellos).
    • Colecciones: Repetición de valores o elementos de un mismo tipo (no necesariamente tipos intrínsecos)
    • Entidades: Valor compuesto por una o más propiedades, las cuales pueden ser de tipo escalar o compuestas.

  • Tipos: Un tipo describe una entidad lógica, compuesta por un nombre determinado y un conjunto de valores. Los tipos en M se pueden clasificar en dos grandes grupos:

    • Intrínsecos: Tipos nativos (y escalares) del lenguaje. En esta categoría encontraremos entre otros: Number, Decimal, Integer, Integer32, Date, DateTime, Text…
    • Derivados: Declarados por el usuario y compuestos por varios tipos escalares y/o derivados. Normalmente se definen en lenguaje M mediante el uso de la instrucción type.

  • Extensiones: Una extensión proporciona almacenamiento dinámico para cualquier valor. Pueden derivarse de otros tipos o ser especificadas directamente. En función del ámbito en el cual declaremos la extensión, ésta generará código T-SQL para crear una nueva tabla al compilar el módulo de M, o al instanciar un tipo que la utilice. Por ejemplo, dada la siguiente declaración de un módulo…

   1:  module Northwind {
   2:      type Employee {
   3:          LastName : Text;
   4:          FirstName : Text; 
   5:      }
   6:      Employees : Employee*;
   7:  }


Al compilarlo se generará el siguiente código T-SQL:


   1:  create table [Northwind].[Employees]
   2:  (
   3:    [FirstName] nvarchar(max) not null,
   4:    [LastName] nvarchar(max) not null
   5:  );


Sin embargo, también podemos «provocar» la creación de tablas sin necesidad de crear un nuevo tipo, de la siguiente forma:


   1:  module Northwind {
   2:      Addresses 
   3:      { 
   4:          {Id=1, Folder=1, State=«NC», Zip=28173},
   5:          {Id=2, Folder=1, State=«WA», Zip=55555}
   6:      };
   7:  }


Dicha construcción en M generará el siguiente código T-SQL:


   1:  create table [Northwind].[Addresses]
   2:  (
   3:    [Folder] int not null,
   4:    [Id] int not null,
   5:    [State] nvarchar(max) not null,
   6:    [Zip] int not null
   7:  );
   8:  go
   9:  insert into [Northwind].[Addresses] ([Id], [Folder], [State], [Zip])
  10:   values (1, 1, N‘NC’, 28173)
  11:  ;
  12:  insert into [Northwind].[Addresses] ([Id], [Folder], [State], [Zip])
  13:   values (2, 1, N‘WA’, 55555)
  14:  ;

Por último, y para ser exactos, diremos que M no es tan sólo un lenguaje, sino una serie de características y reglas gramaticales comunes para toda una familia de lenguajes de modelado. Actualmente, disponemos de tres lenguajes específicos, distribuidos con la CTP de Octubre de 2008 de Oslo:




  • MGraph: Permite serializar datos a estructuras de grafos, con una sintaxis similar a la de lenguajes como JSON. El grafo construido por MGraph es de tipo DAG (Grafo Acíclico Dirigido), el cual proporciona una estructura mejor organizada y eficiente a la hora de ser recorrida que la de un árbol (empleada en lenguajes tipo XML, XAML, etc.)


  • MSchema: Gramática construida sobre MGraph, cuenta con una serie de esquemas predefinidos para la creación, almacenamiento y cálculo de datos.


  • MGrammar: También conocido como Mg. MGrammar es un lenguaje para definir lenguajes. Nos proporciona una serie de construcciones para definir gramáticas (de forma similar a como indicábamos en el post anterior) y traducirlas a MGraph.

A través de MGrammar podríamos definir nuestros propios lenguajes, y de hecho ya hay unos cuantos ejemplos desarrollados, que nos permiten definir servicios WCF (MService), máquinas de estados WF, etc.


En próximos posts veremos cómo crear nuevos modelos y lenguajes, compilarlos y almacenarlos en el repositorio de modelos para su posterior uso desde entornos de ejecución .Net (a pesar de que Oslo sirve para modelar sistemas funcionando sobre CUALQUIER entorno de ejecución).


Enlaces relacionados:



  1. MSDN Oslo Developer Center

  2. M Language Specification: También disponible «físicamente» en el siguiente libro.

  3. M Grammar Language Specification

¿Qué papel juega Oslo en la programación concurrente?

Hace un par de días estuve leyendo un interesante post del bueno de Rodrigo Corral acerca de los retos que la programación concurrente planteará en nuestros desarrollos en un futuro próximo, dada la emergente utilización de procesadores multinúcleo, y la necesaria búsqueda de eficiencia y productividad en nuestras aplicaciones. Uno de los comentarios que surgieron en dicho post se cuestionaba acerca de qué forma Oslo podría «casar» con este escenario, ya que chocarían por una parte la necesidad de acceder a las capas más bajas de abstracción de nuestra aplicación (para poder modificar ad-hoc el comportamiento concurrente de nuestro software en función de las características computacionales, es decir, el nº de CPUs, % de ocupación, etc., en cada escenario) con la abstracción que Oslo pretende conseguir, a fin de posibilitar una «programación más fácil», basada en el uso de lenguajes específicos del dominio en que estemos moviéndonos en un problema concreto. Oslo nos permitirá definir estos lenguajes de forma sencilla, definir su gramática y dotarla de expresividad cercana incluso a la del lenguaje natural (digamos Español, Inglés, etc). Esta expresividad permitirá abrir el mundo de la programación a personas sin conocimientos previos en lenguajes de propósito general como C/C++, Java, C#, VB.Net… El propósito no es dejar sin trabajo a millones de programadores, ni mucho menos, sino conseguir que otros perfiles dentro de la empresa puedan modificar comportamientos concretos de nuestro software de forma intuitiva y sin necesidad de añadir tareas en la agenda ya de por sí apretada del programador. De esta forma estaremos consiguiendo una mayor agilidad en nuestros desarrollos, objetivo perseguido por las arquitecturas SOA.

Me pareció una pregunta bastante interesante y por ello voy a tratar de dar un primer diseño empleando Oslo, para afrontar el problema. Vaya por delante, no obstante, que el propósito no es desarrollar la solución completa sino más bien explicar las líneas de pensamiento que considero apropiadas en el diseño, y de qué forma las herramientas que componen Oslo me ayudarían a simplificar el proceso. Me gustaría recalcar en este punto el concepto de «líneas de pensamiento», ya que hablar de Oslo implica necesariamente hablar de modelos, y un modelo es la representación abstracta de una realidad, o mejor dicho, de un modo concreto (el mío, ya que en este caso me pongo en la piel del arquitecto/diseñador del sistema) de entender dicha realidad.

Volviendo al contexto de la Programación Concurrente, cabe dar una definición concisa y correcta acerca del marco en que nos vamos a mover: (Extraído de Wikipedia)

«La computación concurrente es la simultaneidad en la ejecución de múltiples tareas interactivas. Estas tareas pueden ser un conjunto de procesos o hilos de ejecución creados por un único programa. Las tareas se pueden ejecutar en un sola unidad central de proceso (multiprogramación), en varios procesadores o en una red de computadores distribuidos.»

Felizmente, nada que los lectores de este post no sepáis ya. Así que obviaremos definiciones profundas y me limitaré a recalcar el concepto de Tarea, entendido como conjunto de instrucciones o acciones que precisan de una entrada (datos) y tras su procesamiento devuelven una salida (más datos). Si me lo permitís, a partir de ahora utilizaré indistintamente los términos Tarea y Agente (partiendo de asumir que una tarea o acción requiere de un actor o agente que la efectúe).

Además, tenemos dos mecanismos básicos para la sincronización de estas tareas en programación concurrente:

  1. Uso de segmentos de memoria compartida: A menudo diferentes tareas deben hacer uso de los mismos recursos (por extensión, de las mismas zonas de memoria, variables, estructuras…). Una forma de sincronizar estas tareas y también de garantizar el buen uso de estas zonas compartidas (de ahora en adelante «secciones críticas») es regular el acceso de cada tarea a la sección crítica. De esta forma aseguramos que sólo una tarea accede a la sección crítica en un instante Ti, y que además el resto de tareas accederán a la sección crítica cuando la tarea anterior haya finalizado su interacción con la misma, y por supuesto el acceso será ordenado en base a un cierto criterio. Existen infinidad de formas (semáforos, monitores, etc.) de manejar estas políticas de asignación y prioridad (First Come First Served, Round-Robbin, etc.), por tanto recomiendo acudir a textos que se centren en Programación Concurrente para quienes quieran profundizar en esto.
  2. Intercambio de mensajes: Envío/recepción de mensajes entre diferentes Agentes. Estos mensajes constituyen una forma «educada», de dar paso a la siguiente «persona» (agente) al baño (Sección Crítica), después de haberlo usado nosotros. Estos mensajes pueden ser de dos tipos:
    1. Bloqueantes: «Te espero hasta que salgas para volver a la barra».
    2. No bloqueantes: «Me voy a seguir con lo mío, si necesitas algo ahora en salir me buscas otra vez». 🙂

Por otra parte, es necesario recordar dos principios bastante frecuentes en el uso de datos extraídos de la memoria:

  1. Localidad temporal: Existe alta probabilidad de emplear un dato que acabamos de utilizar.
  2. Localidad espacial: Existe una alta probabilidad de que vayamos a necesitar un dato cercano en la memoria al dato que acabamos de utilizar.

Estos dos principios son muy habituales, no sólo en programación concurrente sino en otros dominios como puedan ser las aplicaciones web, las bases de datos, los conjuntos de variables…

Con todo esto, acabamos de llegar intuitivamente a una aproximación de la realidad bastante parecida al conocido Modelo de Actores, empleado desde el año 1973 en el mundo de la programación concurrente. Perfecto, 35 años después, Miguel acaba de reinventar la rueda.

Pero este capítulo de Barrio Sésamo que me he marcado en un momento no ha sido del todo involuntario, sino que he querido llevar nuestro razonamiento por una vía que nos ha conducido al punto perfecto para comenzar a hablar de Oslo en Programación Concurrente. Mirad qué dos palabras hemos empleado en los dos párrafos anteriores: «Dominios» y «Modelos«. Estas dos palabras son la A y la B de Oslo, la C sería la Capacidad para trabajar fácil e intuitivamente con ellos, para comunicarlos y compartirlos, para refinarlos y readaptarlos, y en definitiva, para que sean elementos centrales en nuestros desarrollos: Model-Driven Development.

Veamos qué forma tiene nuestro Modelo de actores:

image

Nos encontramos con un conjunto de tareas/actores/agentes independientes entre sí. Dichos agentes pueden ejecutar sus operaciones en un mismo procesador, en distintos procesadores de una misma máquina, o en distintos equipos. Lo que está claro es que dichos agentes van a necesitar comunicarse entre ellos, para ponerse de acuerdo (sincronizarse) y por tanto emplearán un canal para ello. Dicho canal dispondrá de un «acuerdo» entre emisor y receptor para definir las posibles acciones entre ellos. En un alarde de originalidad, bautizaré este concepto con el nombre de «Contrato». Efectivamente, por segunda vez en este post, he reinventado la rueda.

Seguidamente vamos a modelar todo esto con el lenguaje de modelado de Oslo, el lenguaje M. Para ellos, abriremos Intellipad y declararemos una serie de entidades similares a las siguientes:

image

Como véis, la sintaxis del lenguaje M es bastante intuitiva. No me creo que alguno de vosotros tenga dudas sobre lo que hemos creado aquí. De todos modos, en futuros posts me centraré en particularidades del lenguaje, y también podéis acudir al MSDN Oslo Developer Center, donde encontraréis todo, todo y todo sobre Oslo, y por supuesto sobre M.

Sobre esta base, podemos aplicar muchas de las bondades de Oslo. Por ejemplo, podríamos crear una gramática con MGrammar (uno de los componentes del lenguaje M) que nos permitiera crear grafos PERT de tareas, como por ejemplo el siguiente.image

Gracias a MGrammar podríamos definir una gramática que permitiera a cualquier persona expresar dicho grafo con las siguientes palabras:

Crea T1. Crea T2. Crea T3.

Crea T4. Crea T5.

T2 depende de T1. T3 depende de T1.

T4 depende de T2 y T3.

T5 depende de T4.

A su vez, podríamos definir gramáticas más complejas que nos permitieran expresar en lenguaje natural las funciones a realizar por cada tarea. O también sentencias del tipo:

T1 ejecuta Suma de 3 y 4.

Donde «Suma de 3 y 4» podría traducirse por Sum(3, 4). O cualquier otra cosa que se nos ocurra.

Igualmente podríamos disponer de sentencias específicas de la programación concurrente, a la hora de definir dependencias. Por ejemplo:

T2 depende exclusivamente de T1.

T3 depende de T1 y T2. (de ambas)

T3 depende de T1 ó T2. (basta con que una tarea de ambas termine para que T3 pueda comenzar)

Todo esto sería fácilmente representable mediante el uso de MGrammar. No me detengo en expresarlo formalmente porque me pierdo la cena navideña, pero si el ejemplo os gusta, prometo avanzar en él.

Una vez generada la gramática, podríamos traducir dicho código a diferentes runtimes: ASP.Net, Dublín, WCF/WF… Es decir, podríamos traducir dichas dependencias y tareas a código CLR, o a cualquiera de los lenguajes de la familia .Net, e igualmente definir en dicha traducción cuantos comportamientos específicos del hardware queramos.

La labor de Oslo será dotar de mecanismos de alto nivel mediante el uso de gramáticas como la descrita anteriormente, lenguajes específicos de dominio textuales, y visuales (Quadrant). para que cualquiera pueda convertirse en desarrollador (a pesar de que ellos no lo sepan).

Por último, para quien en este punto se mantenga reticente al uso de lenguajes específicos de dominio en el ámbito de la programación concurrente, le recomiendo ver el siguiente vídeo publicado hace un par de días en Channel 9, acerca de MAESTRO, un proyecto de investigación orientado a la definición de lenguajes específicos de dominio para la programación concurrente en código .Net manejado.

Feliz Navidad!

 

 

 

Más Windows Live Writer: Twitter, Live Mesh y gadget para Windows Vista

Me uno a la serie de posts sobre Windows Live Writer que uno de los nuevos «fichajes» de Geeks, Roberto Vivancos, está realizando esta semana. Antes que nada, destacar su último post con 10 plugins muy interesantes para Live Writer.

Y, al margen de estos 10 plugins, me gustaría añadir otros 3 más a la lista:

  • Plugin para Live Mesh: Como no podía ser de otra forma (y dado mi amor declarado a Live Mesh), este plugin para mí se lleva el primer premio. Se trata de un plugin que permite sincronizar tus borradores entre distintos equipos gracias a Live Mesh. ¿Cuántas veces has comenzado a escribir un post en la oficina y te han dado las tantas por querer terminarlo antes de volver a casa? Ahora eso puede pasar a ser historia, únicamente instala WLW en tu PC de la oficina y de casa, instala este plugin, y sincroniza los borradores de uno y otro WLW a través de tu cuenta de Live Mesh!!

 

 Saludos @…

image

Tratado básico de Zoología Informática: Especies singulares de bugs y cómo combatirlos

Tradicionalmente, podríamos definir el término «bug» (de cuyo origen etimológico, sea leyenda urbana o realidad, ya hablamos hace tiempo por aquí) como un defecto, fallo o error del código de nuestra aplicación que deriva en un comportamiento anómalo de la misma, causando un resultado inesperado en nuestro programa.

Esta definición, de por sí bastante clara e intuitiva, es por otra parte demasiado genérica ya que bajo el término «bug» englobamos demasiadas mutaciones de los mismos. Partiendo de la base de que cada fragmento de código es singular y cada escenario diferente, lo cual da lugar a bugs de muy diversa índole, sí que es posible realizar una cierta taxonomía o clasificación de bugs en base a su comportamiento, o a la forma en que se manifiestan con mayor o menor frecuencia, e incluso de forma completamente impredecible.

Veamos algunos de estos tipos, así como los rasgos principales que los caracterizan y, por tanto, algunas estrategias de alto nivel que nos permitirán luchar contra ellos con ciertas garantías de éxito.

Bug atómico o Bohrbug

bicho

  Origen del término: Este bug básico debe su  nombre al Modelo Atómico de Bohr, y al igual que dicho modelo atómico, considera el bug como un elemento simple e indivisible, con características bien definidas y siempre deterministas.

  Características: El bug sencillo, claramente identificable y dependiente de una serie de factores estáticos. Este bug siempre se va a manifestar en la ejecución de nuestro programa si se dan las precondiciones o causas que lo propician.

  Posibles antídotos: Una forma efectiva de identificar estos bugs consiste en la realización de pruebas unitarias de acuerdo con la especificación de nuestro software. Es muy importante que estos bugs, de naturaleza sencilla, sean identificados lo antes posible en nuestros desarrollos, para evitar costes adicionales en su reparación. 

 

El bug estadístico

bug

Características: Bugs basados en pruebas estadísticas de nuestro software. A priori, son algo más complejos de identificar que los Bohrbugs, porque no se manifiestan en todas las ejecuciones de nuestro software. Sin embargo, la repetición cíclica de una misma prueba los pone de manifiesto, y a la larga comprobamos que responden a un patrón de comportamiento bien definido. Se trata de bugs del tipo: «Mi programa siempre falla en la N-esima invocación de cierto fragmento de código, a pesar de que las anteriores ejecuciones de este mismo método han funcionado perfectamente»

Posibles antídotos: La ejecución de pruebas estadísticas y pruebas de stress basadas en perfiles operacionales concretos de nuestras aplicaciones nos permiten detectarlos con relativa facilidad. Una vez detectados, la complejidad del escenario determinará la complejidad a la hora de identificar claramente las condiciones que los producen, y en base a ello, las medidas a tomar para mitigarlos.

 

El bug «efecto demo»

  Origen del término: Las primeras menciones a este término provienen del Alemán, el vocablo original es «Vorführeffekt» y significa efecto demo/presentación. Me gusta asociar este bug con el «adorable» Gizmo, nuestro programa puede ser igualmente adorable pero un pequeño descuido por nuestra parte puede dar lugar a la aparición de una criatura completamente diferente…

  Características: Nadie está libre de este tipo de bugs, y probablemente por vuestras mentes estén pasando ahora mismo situaciones célebres en la historia del software en las cuales estos bugs se han manifestado (jeje). En la aparición de este bug siempre influye el hecho de que el amigo Murphy nos visite o no en un determinado día… Este bug va siempre seguido de la manida excusa: «esto funcionaba ayer en casa». ¿Os suena?

  Posibles antídotos: Nunca te confíes. Si vas a dar una presentación en un determinado lugar, prueba siempre tus demos en este lugar. Si vas a emplear una determinada resolución de pantalla, asegúrate de que tu demo funciona con esta resolución. En general, verifica que todos los requerimientos de tu demo estarán disponibles en el momento en que la vayas a realizar (conexión a Internet, etc). Debes prestar especial atención a condiciones de «timeout» de tu aplicación o similares, las cuales pueden causar que incluso el bug se manifieste en un lugar en el que minutos antes de la presentación todo parecía funcionar a las mil maravillas. 

 

El bug de las Fases Lunares

Origen del término: A todos os resultará familiar la historia del hombre lobo… De igual forma, nuestro software puede adoptar comportamientos anómales en un momento determinado, una fecha determinada, etc.

Características: Se trata de un caso más o menos obvio de Bohrbug, pero que a su vez contiene un componente relacionado con cierto grado de arbitrariedad en nuestro programa.

Posibles antídotos: Prestemos especial atención a los comportamientos que se produzcan en nuestro software debido al uso de ciertos elementos, como por ejemplo funciones de fecha/hora.

 

El bug latente (Schroedinbug)

cartoon_bug

  Origen del término: El bug debe su nombre al famoso «experimento del gato de Schroedinger«

  Características: Nuestro programa funciona perfectamente durante semanas, meses, años… Llegado cierto día, un usuario detecta cierto bug en el sistema y, a partir de este momento, el resto de usuarios comienzan a experimentar el mismo fallo en cascada.

  Posibles antídotos: Este bug está especialmente relacionado con sistemas basados en máquinas de estados. El momento puntual en que se produce el primer fallo coincide con una transición no controlada dentro de dicha máquina de estados. El resto de fallos en cascada se producen por haber alcanzado lo que en la teoría de grafos se conoce como «estado de absorción» de nuestro grafo. Por tanto, deberemos poner especial atención en el diseño de estos sistemas. Esta especie de bug pone especialmente en relieve la importancia del software testing desde las primeras fases de especificación y diseño del sistema. Probablemente un análisis riguroso de las primeras aproximaciones del diseño nos habría permitido detectar estados no controlados del mismo, y redefinir dicho modelo de manera efectiva. Una detección tardía de este bug, como en la mayoría de casos, deriva en un incremento exponencial de los costes de reparación, lo cual repercutirá drásticamente en los costes de desarrollo de todo el proyecto.

 

El bug intrínseco o estructural (Mandelbug)

Origen del término: Este bug debe su nombre a Benoit Mandelbrot, matemático francés considerado el padre de la teoría de los fractales matemáticos. Dicha teoría, a grandes rasgos, proclama que un sistema puede descomponerse en pequeños fragmentos, los cuales son a su vez copias idénticas de menor tamaño que el sistema completo.

Características: Se trata de bugs que se manifiestan en escenarios de uso concretos de nuestro software, pero dichos escenarios no son más que «la punta del iceberg», puesto que son causa directa de fallos estructurales del diseño de nuestro software. El principal problema a la hora de resolver estos bugs radica en que, a menudo, las causas que producen estos bugs son (al igual que los fractales) una conjunción de elementos cuya percepción y diferenciación es demasiado compleja, con lo cual no es posible identificarlos claramente.

Posibles antídotos: Disponer de un diseño iterativo claramente definido acerca de nuestro sistema, y las relaciones y correspondencias entre los niveles de abstracción del mismo son herramientas que ayudarán a la hora de identificar las relaciones causa-efecto en estos casos. A pesar de que en muchas ocasiones consideramos suficientes e independientes los enfoques de diseño «top/down» y «bottom/up», conviene realizar ambos como mecanismo para una mejor compresión (y revisión) de las particularidades del sistema.

 

El bug indeterminista (Heisenbug)

bichos-03

  Origen del término: El bug indeterminista debe su nombre al físico Heisenberg y su famoso principio de Incertidumbre (no-determinismo).

  Características: Dado un determinado escenario de uso de nuestro software, las mismas acciones realizadas exactamente en el mismo orden producen una ejecución satisfactoria o un fallo. El análisis estático de nuestro software es claro, y la conclusión que de él extraemos es que todo debería funcionar a la perfección, sin embargo hay un determinado «duende» que juega con nuestro software (y nuestra paciencia) y hace aflorar un bug de manera arbitraria.

Se trata de ese tipo de bugs a los cuales dedicamos horas y horas de investigación, tazas y tazas de café y finalmente lo damos por imposible, o tal vez no… Todo dependerá de la tenacidad, perspicacia y capacidad de análisis metódico y ordenado del Ingeniero de Pruebas a la hora de diseñar el Plan de Pruebas ideal para cazar este bug tan escurridizo.

  Posibles antídotos: Generalmente este tipo de bugs se manifiestan en pruebas de integración o del sistema, siempre y cuando entendamos correctamente el significado de éstas. Consideramos dentro de este grupo a todas aquellas pruebas que contengan dependencias volátiles. Puedes encontrar una explicación acerca de estas dependencias volátiles en los materiales de mi última presentación en Gusenet, acerca de Windows Communication Foundation, en la cual analizamos diferentes tipos de pruebas sobre servicios. Como regla general, deberemos eliminar todo factor que introduzca indeterminismo en nuestro sistema: uso de funciones aleatorias (Math.Random), uso de librerías de terceros cuyo comportamiento no seamos capaces de controlar completamente, etc.

Dentro de esta última categoría de bugs, incluiremos también aquellas situaciones propias de entornos concurrentes (en las cuales el elemento causante de indeterminismo es la propia política del planificador de tareas de cada máquina, para cada ejecución), como pueden ser los interbloqueos (deadlocks), esperas ocupadas, colisiones en segmentos de memoria críticos, acceso exclusivo a recursos, etc.

Para esta última categoría, Microsoft Research está desarrollando una herramienta que permite analizar y simular de manera sistemática y determinista la planificación de procesos concurrentes. La herramienta en cuestión se denomina CHESS, y puedes encontrar información en la página web del proyecto, así como en el siguiente vídeo de Channel 9 con el equipo de desarrollo del proyecto, así como en esta sesión del PDC.

Si dispones de un par de horas para ver vídeos, te recomiendo invertirlas en aprender acerca de este interesante proyecto.

Student Technology Day en UK [videos imprescindibles]: Keynote de Steve Ballmer, el futuro de las interfaces de usuario y políticas de indexación en Windows Live Search

Hace unos días tuvo lugar en UK una interesante conferencia organizada por Microsoft, y enfocada a estudiantes, de la cual me gustaría destacar los siguientes vídeos (disponibles en Channel 8).

  • Keynote de Steve Ballmer: Durante el discurso de apertura, Steve Ballmer destacó algunos de los retos que la industria del software está afrontando y afrontará en los próximos años, así como el papel de los estudiantes en esta tarea. Al mismo tiempo, da una idea acerca de la importancia de la captación de talento, la investigación y la innovación como ejes fundamentales para el futuro de las grandes empresas de software.

  • El futuro de las interfaces de usuario: Uno de los mayores retos a afrontar en el campo del diseño de interfaces de usuario es de qué forma dos elementos «clásicos» en la interacción humano-máquina (HMI) como son el teclado y el ratón se verán gradualmente reemplazados por tecnologías de tipo táctil. Descubre en esta sesión algunos de los conceptos de usabilidad, accesibilidad y arquitectura subyacentes en el diseño/desarrollo de este tipo de interfaces.

  • La ciencia oculta tras Live Search: El último de los vídeos que destaco de este evento es una sesión impartida por Jay Girotto (Program Manager del equipo de Live Search) en la cual habla acerca del proceso de investigación e ingeniería que se aplica para diseñar las políticas de indexación y búsqueda de Live Search, a la hora de gestionar «toda» la información contenida en Internet.

Para finalizar el post, os dejo una imagen «muy navideña», producto de la primera nevada de la temporada en Vancouver a nivel del mar, la cual está sucediendo ahora mismo (real-time blogging)… Sin duda un fin de semana ideal para ver algunos vídeos pendientes y también retomar el blog, el cual (pido disculpas) tenía algo abandonado en las últimas semanas.

BurrardBridgeLg

Pronto nuevas entradas al respecto de Oslo, centradas en algunos ejemplos guiados y posibles escenarios de uso (tal cual habeis estado pidiendo muchos) y también alguna que otra reseña «de cultura general» acerca de bugs y Software Testing.

Happy Weekend!

Guía de Bloggers para adentrarse en "Connected Systems 1.0" (Oslo, WCF/WF, Azure y Dublin)

Mucho se ha hablado por la blogosfera en las últimas semanas acerca de la nueva oleada de tecnologías que Microsoft dio a conocer en el pasado PDC. Tanto es así, que nunca viene mal un filtrado y selección de aquellos posts más relevantes o representativos de estos temas.

Para tal fin, se ha elaborado una recopilación de algunos de estos posts escritos por autores de la talla de Darren Jefford, Charles Young, Andreas Erben, Imran Shafqat, Don Box, Brian Losegen, Aaron Skonnard, Jeff «Pinkey» Pinkston y Martin Fowler.

En esta recopilación de posts se habla largo y tendido sobre la visión de Oslo a medio y largo plazo, el lenguaje de modelado M, la nueva visión de Microsoft sobre SOA, el futuro de BizTalk ligado a Oslo, así como la relación entre Oslo, Windows Communication Foundation y Workflow Foundation. También se recopilan posts sobre Dublin (y sus similitudes/diferencias con respecto a BizTalk Server) y Azure .Net Services.

Podéis encontrar esta guía aquí.

Nota: Al descargar el archivo CHM, deberéis acceder a la ventana de Propiedades del mismo y Desbloquear el contenido (bloqueado automáticamente por seguridad). De no hacerlo, no veréis el contenido HTML del mismo.

Sesiones sobre Oslo en el PDC 2008

Con algunos días de retraso sobre mi intención inicial, espero que aceptéis mis disculpas, voy a comenzar a publicar algunas entradas al respecto de Oslo y todo lo acontecido en torno a esta nueva tecnología en el PDC, celebrado la pasada semana en Los Ángeles.

En primer lugar, y a modo de recopilación, os dejo los enlaces para la descarga directa de los vídeos de cada una de las sesiones, junto con un breve resumen de cada una. Al margen de realizar la descarga del vídeo, podéis visualizarlos directamente en la web del PDC, concretamente en esta sección.

Personalmente, prefiero la visualización en la propia web, ya que muestra el doble enfoque sobre el speaker y también captura el escritorio del PC donde se presentan los contenidos, mientras que en los vídeos para descarga tan sólo se muestra el escritorio de la presentación (me gusta ver algo más de movimiento en pantalla, especialmente con speakers con gran riqueza expresiva como Don Box, Douglas Purdy y algunos más que intervinieron en estas sesiones).

Las sesiones realizadas sobre Oslo fueron las siguientes (pinchad en la imagen para abrir el link con la sesión y los formatos para descarga del video, así como de las slides):

  • “A Lap Around Oslo”: En esta sesión, como su propio nombre indica, se realizó un recorrido general por todas las novedades y características de Oslo, de la mano de nuestro súper Ninja Vijaye Raji (creador del lenguaje Small Basic, del cual os hablé hace unos días por aquí también) y de un más que entregado a la sesión y a la audiencia Douglas Purdy. Recomiendo comenzar por esta sesión especialmente a aquellos que quieran una introducción general a la tecnología y un repaso de su arquitectura a modo top-down, y también por supuesto a todos los demás, ya que se trata de una sesión bastante dinámica y entretenida. Una ideal primera toma de contacto con Oslo.

  • “Oslo: The Language”: Esta fue la segunda sesión sobre Oslo en el PDC, y en ella uno de nuestros Arquitectos David Langworthy y el querido y distinguido señor Ingeniero Don Box hacen un profundo repaso al nuevo lenguaje de modelado que Oslo nos aporta: el lenguaje M. Como veréis en esta sesión y también en próximas entradas en este blog, el lenguaje M nos proporciona una gran riqueza expresiva a la hora de definir modelos para complementar sistemas de tipo declarativo, como por ejemplo Workflow Foundation (WF) y Dublín (sobre lo que también os hablaré por aquí pronto). Además, se realizan varias demos mostrando el potencial de este lenguaje, algunas de sus características sintácticas para crear instancias y realizar consultas, y también el entorno textual con el que trabajaremos (viene incluido en la SDK de Oslo, de la cual, nuevamente, prometo hablar pronto) y que no es otro que Intellipad, con una serie de extensiones y configuraciones especiales “built-in”.

  • “Oslo: Customizing and extending the Visual Design Experience”. Ya en el tercer día de sesiones, le tocó el turno a uno de nuestros Program Managers, Florian Voss, acompañado nuevamente de un Don Box al estilo hawaiano, de profundizar en el uso de la herramienta visual de diseño que Oslo nos proporciona: Quadrant. Entre las características de esta herramienta destaca su alta capacidad de personalización a la hora de visualizar entidades (posición en el gráfico, coloreado contextual en base a valores de cada parámetro visualizado, así como otras muchas cosas más), y también la capacidad de consultar y almacenar modelos en el repositorio de Oslo. Como primera curiosidad/demostración del potencial de Oslo, comentar que todas estas opciones de configuración del diseñador constituyen nuestro “Modelo de Quadrant” y son almacenadas “in the cloud” en el propio repositorio de modelos: Oslo se modela a sí mismo, señores. 🙂

  • “Oslo: Repository and Models”: Uno de los objetivos fundamentales de Oslo es minimizar las barreras entre distintos tipos de modelos empleados en el proceso de desarrollo de software, de manera que todos ellos se almacenen de igual forma y sea la vista sobre dichos modelos la que se configure en función de qué es lo que queremos visualizar en cada momento (arquitectura, diagrama conceptual de entidades, etc). En esta sesión, los PMs Martin Gudgin y Chris Sells se encargan de enseñarnos cómo extender modelos, cómo añadir nuestros propios modelos al repositorio, y también aprenderemos a versionar, proteger y desplegar modelos.

  • “Oslo: Building Textual DSLs”: Para poner el broche final a la presencia de Oslo en este PDC, Chris Anderson y Giovanni Della-Libera nos enseñarán de qué forma el lenguaje M nos permite definir esquemas y transformaciones sobre textos. A modo de ejemplo, nos muestran cómo construir nuestro propio DSL utilizando la SDK de Oslo y cómo emplear dicho DSL para crear un editor de textos bastante interactivo.

Y eso es todo por ahora, podéis ir en paz, no sin antes recordaros por mi parte que en breve encontraréis nuevos posts, tutoriales, vídeos y otra serie de materiales de apoyo para reforzar y profundizar en el contenido de todas estas sesiones. También me gustaría que ante cualquier duda, sugerencia inquietud o feedback oportuno dejéis algún comentario en este post, prometo contestar a todos 🙂

Happy Weekend!

Una de las tecnologías más asombrosas que he visto en mucho tiempo

Probablemente muchos de vosotros recordaréis Live Mesh. Para aquellos que no, comentar que Live Mesh es una de las tecnologías por las que siento una especial predilección y cuya adopción considero clave en la evolución del mundo de la Informática en los próximos años. Además, comentar que Live Mesh forma parte de la plataforma de desarrollo de Windows Live (y por tanto, de uno de los bloques de servicios ofrecidos como parte de Windows Azure), y su objetivo fundamental es proporcionar una serie de servicios y APIs de desarrollo para que podamos construir aplicaciones que consuman cloud services. Concretamente, el tipo de servicios en la nube que Live Mesh nos ofrece es fundamentalmente la compartición y sincronización de archivos, opciones de configuración y personalización para cada usuario entre un conjunto (mesh) de dispositivos, esto es, tener toda nuestra información a nuestro alcance desde todos los dispositivos que utilicemos: PC de sobremesa, PC portátil, dispositivo Windows Mobile, etc.

Las posibilidades que ofrece esta tecnología (con cuyas APIs podremos comenzar a trabajar dentro de poco) son prácticamente infinitas, únicamente limitadas por nuestra capacidad de imaginación. Quizá recordaréis este post en el cual os mostraba un vídeo en el que Ori Amiga (uno de los creadores de esta tecnología) nos hacía una introducción a la plataforma de desarrollo de Live Mesh. No obstante, siempre es más cautivador de cara al usuario final visualizar un escenario de uso de la tecnología en la cual se haga uso de gran parte de su potencial, y eso es precisamente lo que se ha pretendido en esta ocasión.

El escenario de uso es el siguiente: Imaginad ir en vuestro coche de camino a una reunión de trabajo y poder escuchar toda esa música que tenéis en vuestros PC’s de casa, del trabajo, etc. También podríais ver películas, concertar citas, enviar SMS de forma automática a los compañeros de reunión para avisarles de cuánto tiempo os falta para llegar a la oficina, basado en cálculos de distancia y tiempo restante extraídos de Live Maps, y todo ello integrado con vuestro dispositivo GPS. Además, el sistema sería capaz de acceder a la información de nuestro vehículo (kms recorridos, gasolina restante, niveles de aceite, etc) e incluso enviar automáticamente avisos a nuestro teléfono, o sincronizar en nuestro calendario de Outlook una cita con el mecánico para realizar la revisión periódica de nuestro vehículo… Y lo mejor: toda esta información, archivos multimedia, calendario, contactos, servicios adicionales… reside en la nube!! De forma que, incluso, podríamos sincronizar varios coches entre sí, de igual modo que haríamos con el resto de dispositivos… Y acceder a dichos servicios con un simple cliente ligero con pantalla táctil.

¿Suena imposible? Mira el siguiente vídeo de Channel 9 y verás que, con Live Mesh, es completamente posible, haciendo uso del recién estrenado Live Framework, de cuyo modelo de desarrollo puedes descargar un póster aquí. (demo a partir del minuto 20)

Quizá ahora comprendáis un poco mejor el porqué de mi admiración por esta tecnología.