Win8, Silverlight, y otra razón en favor de MDD

Las primeras presentaciones de Windows 8, todavía muy preliminares, han contribuído a crear un revuelo mayúsculo en al menos parte del mundo de desarrolladores de Microsoft, básicamente en la comunidad de Silverlight, y hasta cierto punto también en la comunidad .NET. Según parece (a casi dos años todavía de su lanzamiento), Windows 8 será profundamente distinto, tanto en su diálogo con el usuario, como en las herramientas con las que construirá su interfaz con él. La respuesta pública ha tenido dos caras: de parte del mercado comprador (hogar y socios de negocios interesados en salir al paso de la competencia en tablets y teléfonos inteligentes), expectativas positivas. De parte de la comunidad de socios y desarrolladores que construyen para su arquitectura actual, quejas y desconfianza. ¿Por qué? porque intuyen, tanto a través de las presentaciones, como por lo que no se dice, que las herramientas actuales ya no estarán en el centro del negocio, sino que pueden caer a un mercado secundario, mientras el foco se desplaza a aplicaciones montadas sobre HTML5, CSS3 y javascript. Justin James, en Techrepublic, es uno entre otros muchos, que describen este estado:

There is an absolute firestorm around HTML5-based apps in Windows 8 and where it leaves native app technologies like WPF, Silverlight, and WinForms. I have no idea what is happening for sure, and I guarantee you that all of my Microsoft contacts either do not know or would not tell me if they did, and I respect that. Here is what I do know:

• Windows 8 appears to have an application building engine based on HTML5 technologies (I’m including JavaScript and CSS3 in that umbrella).
• Microsoft stopped pushing Silverlight as a Web app add-in a while ago, and said it was for “out of browser,” cross-platform, and special purposes (like WP7 development).
• WinForms got backburnered with the release of WPF.
• The pace of Silverlight development has slowed significantly as the technology matures.
• Silverlight has been a big success in writing internal applications, and Silverlight is not the pain point in writing WP7 apps (the APIs and their lack of support for many scenarios are).
• Microsoft has displayed a worrisome habit of dropping technologies just as they seem to be fulfilling their potential.
• Silverlight has been increasing its capability for quite some time, heading towards convergence with WPF. The big barrier has been the size of the download; the Silverlight team stated a while back that the installer should never be bigger than Flash’s.

Based on what I know and the current trends, I do not think Silverlight is going away any time soon, but I do think Microsoft is seeing HTML5 as “Silverlight Lite.” Since Silverlight is already “WPF Lite,” It’s conceivable that WPF and Silverlight will merge, basically putting the out-of-browser capability onto WPF, and either taking out the stuff that doesn’t go across platforms or just having two WPF profiles (just as Silverlight has a phone profile that is less capable than the full Silverlight platform). Then, Microsoft can feel free to push its HTML5 apps to folks that like the Silverlight idea but don’t feel comfortable with the technology. This is 100% pure conjecture on my part though. Mary Jo Foley has some interesting information as well, and Laila Lotfi has a good analysis of the situation.

Pongamos esta situación entre paréntesis: falta mucho para que se desenvuelva completamente la ¿nueva? estrategia de Microsoft. En poco más de dos años, se ha producido una explosión de ofertas de arquitecturas, sistemas operativos, y estilos y alcance de aplicaciones. Claramente esta situación clama por otro estilo de desarrollo. Jugarse hoy por una arquitectura puede ser suicida, pero no dedicarse a ella también puede ser una decisión para arrepentirse largamente. Este panorama trae a primer plano a las herramientas que basan el desarrollo en modelos, construyendo la lógica de negocios, o la lógica a secas, en un terreno abstracto, con la capacidad de desplegarla luego en la arquitectura que haga falta. Así, si una arquitectura de pronto va a vía muerta (como quizá pase con Simbian), el patrimonio en aplicaciones desarrolladas no queda atada a la arquitectura, la plataforma, o el framework, sino que es viable desplegarlo en otra alternativa.
Frente a las ocasionales afirmaciones acerca de eventuales debilidades del desarrollo basado en modelos, me cuento entre quienes sostienen que este universo de múltiples galaxias, tiene su llave en MDD. Cuando he presenciado defensas de distintos frameworks, en un momento donde éstos se encuentran en general atados a un puñado de propietarios, he sostenido que jugarse por uno puede significar perder mucho, simplemente si el propietario es comprado o cambia de estrategia (y está claro que Simbian no es el único caso).
El carácter abierto de MDD permite que un ecosistema de herramientas de modelado se acompañe por otro que permita ofrecer generadores que transformen los modelos abstractos a las distintas arquitecturas, plataformas, frameworks y lenguajes. Si el estado hoy es imperfecto, hacia allí se moverá, perfeccionando las soluciones.

Conferencia CGN: Karsten Thoms sobre principios básicos

A falta de oportunidad de participar en la conferencia, dedicaré algunos días a comentar lo que de las presentaciones aparece como más interesante. Soy enemigo de los powerpoints, porque están pensados para servir de guía durante una conferencia o presentación, y acompañan la conversación del disertante, pero reflejan pálidamente lo que el autor conversó. En el caso de la presentación de Karsten Thoms, esta es tan espartana que podría dudarse de cuál fue su contenido. Sin embargo, los diez títulos hablan fuerte y claro. De entre ellos, quiero destacar los siguientes, que coincido en que determinan la factibilidad de usar un generador de código. Interpretaré libremente lo que Karsten explicara, basándome en sus sentencias minimalistas:

Mezclar artefactos cuyo código es generado con otros creados 'a mano' (Mixed Generated/Manual Code Artifacts). Este escenario implica que hay aspectos que, aunque fueran representables en un modelo, no pueden ser traducidos a código. Estos espacios no cubiertos derivan de un generador que ignora aspectos del modelo, y por lo tanto no es capaz de representar la totalidad. Aún cuando pudiera haber casos en que la parte manual (opaca para el modelo) pueda rescatarse, al no tener relación con la descripción abstracta, el esfuerzo de integración corre por cuenta del "codificador manual". Si aplicamos esta falta de integración a modelos complejos y grandes, el esfuerzo de seguimiento de la relación entre las dos partes es peligroso, y posiblemente motivo de fracaso.

No reestructure su código generado (Don‘t Refactor Your Code Generator Code). Aplicar una nueva capa de optimización de código al código generado es doble trabajo, y ganancia de corto alcance, ya que al no afectar al modelo, el código se reproducirá a la siguiente oportunidad. Si su ciclo de desarrollo se basa en iteraciones cortas, la refactorización puede ser agotadora (e inútil a futuro). Esto no quiere decir que no sea bueno refactorizar. Pero debe hacerse sobre el modelo, y sobre las reglas de transformación; es decir, una refactorización bien distinta. El código debe derivar optimizado, no rehecho a posteriori.

Hay otros tres puntos que resultan especialmente interesantes, pero en este caso, trataré de conocer directamente su posición sobre ellos:

• Missing Reference Models /Implementations

• Don‘t Participate Developers

• Requiring The IDE For Execution

 Para seguir a Karsten, su blog.

Esperando noticias de la conferencia...

Entre el 1 y el 3 de junio se desarrolló la conferencia anual de Plex. No habiendo participado, espero las noticias...En unos días, más detalles de lo que el programa anticipaba.
No es la única conferencia de la que espero noticias: también una semana antes se completó la conferencia de Code Generation Network. En este caso, algunos adelantos han dado Pedro Molina, Marco Brambilla, Angelo Hulshout y  Johan den Haan, entre otros. Lamentablemente, estas semanas, poco tiempo para dedicar por anticipado...