STOP Coding - Start ArchitectingLa primera regla que un nuevo desarrollador en Plex debe asumir, es que debe escribir la menor cantidad de código posible: olvidarse de escribir líneas de código, y pensar, pensar el modelo de datos y relaciones, luego estudiar cómo abstraer y explotar patrones existentes, y sólo luego escribir código, sólo lo que es estrictamente necesario. "Whenever there is a hard job to be done I assign it to a lazy man; he is sure to find an easy way of doing it"
Plex development is essentially a three-step process involving Data Modeling, Pattern Matching and Customization. There are no shortcuts, each step must be adhered to achieve the goals. Missing a step may seemingly achieve a short term solution but in the medium and long term the solution will surely decay far quicker than it should have. The mindset required to use plex effectively is one of:
- Object oriented approach to application design to eliminate the need to code repeatable elements of applications
- Working at a level of abstraction rather than at the ‘nuts and bolts’ level, probably just saying the first point again but this can’t be over stressed the importance to think this way instead of coding procedural code line after line
- Model-based and pattern-based approach to increased application quality and flexibility
- Multiple inheritance is a key part of the way applications are developed in CA Plex therefore leveraging the full value of a site’s existing patterns
- Encapsulation so that function interfaces contain only the attributes pertinent to the use of the function
- An application should be separated into separate layers/tiers, Functionality should be strictly separated into data access, business logic and presentation logic, as this promotes the consistency of the application as well as the possibilities to reuse functionality.
Mostrando las entradas con la etiqueta MetaModelos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta MetaModelos. Mostrar todas las entradas
sábado, junio 27, 2015
Una guía de trabajo con Plex
George Jeffcock, en su sitio relacionado con sus Stella Tools, dedica algunos párrafos a recomendar buenas prácticas en el uso de Plex. Coincidiendo con las guías de enseñanza usuales en Plex, George recomienda:
domingo, mayo 24, 2015
Evolución o desajuste: un asunto crítico
De interés para usuarios de Plex; en el último tiempo, varias discusiones importantes se han desarrollado en la comunidad de usuarios en CA. Discusiones que van en dos direcciones: prometedores nuevos desarrollos, y retrasos lamentables en el soporte de nuevas tecnologías. Esta dualidad refleja probablemente la situación del producto: un gran capital en una herramienta robusta que no pierde utilidad, y una respuesta errática a los cambios tecnológicos. Puntualizo algunas de las discusiones, e invito a revisarlas, y en el caso de las ideas propuestas, a votarlas si les parecen adecuadas. Las menciono por su título:
Outlook question: la discusión abierta es acerca del soporte de WinApi, ObMapi, es decir, el sistema de mensajería, para Outlook 2013 (también se menciona Outlook 2010). El problema reside en que el API está soportado para 64 bits, pero no para 32 bits, y Plex es generado para 32 bits. Esta es la respuesta del soporte de Plex:
Sobre este asunto del atraso en el soporte de productos u opciones respecto a la evolución tecnológica actual, hay otra discusión que afecta a 2E, no Plex, pero donde valen las opiniones de los participantes, ya que podrían asociarse sin mucha dificultad también a Plex: la complejidad de plataformas y tecnologías que deberían abarcarse hace difícil mantener el paso. En el caso de Office, el problema resulta aún más claro: los cambios de arquitectura ensayados por Microsoft son capaces de hundir a cientos de proveedores de servicios que trabajan para su plataforma (partners), como sucediera con el mercado de Silverlight, y seguramente con los incipientes desarrollos orietados al cuasi difunto Metro.
Otras discusiones de importancia vienen de la sección de Ideas, por ejemplo la postulación de la generación de servicios REST sobre el System i (discusión especialmente interesante), o las dos o tres referencias a la actalización del soporte de SQL en el System i (1, 2). O incluso las postulaciones a mejoras en el soporte de RPG ILE. Todos ellos hablan de un retraso de soporte a la evolución de las distintas plataformas, que resulta prioritario resolver. Hoy la evolución tecnológica es rápida y diversa, y resulta muy difícil abarcar el espectro completo de arquitecturas, tecnologías y paradigmas. Aún para el paradigma de diseño basado en modelos, resulta difícil seguir el paso para elaborar transformaciones adecuadas a cada caso y sus interrelaciones. ¿Qué camino es más aconsejable en éste caso, el de Plex?
Desde hace años, la solución de las transformaciones para atender nuevas áreas en Plex han estado a cargo de terceros; sea socios de negocios, como en el caso de los desarrollos web, telefonía móvil, e incipientemente cloud por parte de SoftDesign (Websydian) y CM First (WebClient), o los desarrollos para XML de Simon Jasperse, o los minipatterns debidos a Peter Fabel y Luwdig Hirth, o Stella Tools de George Jeffcock. Probablemente este sea el mejor modo de poder atender, especialmente sin un elevado presupuesto de investigación, la avasalladora ola de cambios en que nos movemos.
También desde hace años, el equipo de desarrollo de Plex expone crecientemente el API que permite la interrogación y operación del modelo, sus objetos y sus métodos. Es gracias a ésto que herramientas como Stella Tools puede trabajar. Probablemente esta vía sea la mejor para el desarrollo del modelador y sus generadores. Sería muy positivo que el trabajo del laboratorio de desarrollo de Plex se concentrara en éste aspecto: los modos para extender el modelador, para extender la inclusión de nuevos generadores que puedan ser elaborados por terceros. Estos terceros podrían ser empresas interesadas en extender la generación de código final a un nuevo área, o empresas interesadas en adecuar una extensión a sus propias necesidades. Al modo en que Xtext trabaja hoy como DSL. Creo que ésta es la salida viable de Plex en éste momento, y allí deberían centrarse los esfuerzos.
Outlook question: la discusión abierta es acerca del soporte de WinApi, ObMapi, es decir, el sistema de mensajería, para Outlook 2013 (también se menciona Outlook 2010). El problema reside en que el API está soportado para 64 bits, pero no para 32 bits, y Plex es generado para 32 bits. Esta es la respuesta del soporte de Plex:
La solución ofrecida es usar la versión de Office de 32 bits, o usar otro código, o solicitar al equipo de desarrollo que estas APIs soporten 64 bits. El propio soporte recomienda esta última opción, que conduce a una solicitud existente desde julio de 2014.There is a compatibility issue between the 64-bit versions of Microsoft Outlook and other 32-bit applications. Since Plex generates 32-bit application, you will need to use the 32-bit versions of Outlook. (remite a la explicación de Microsoft). So, if you are using the OBMAPI or WINAPI Souce Code mail APIs, then you will not be able to use the 64-bit version of Outlook 2013 with these APIs.
Sobre este asunto del atraso en el soporte de productos u opciones respecto a la evolución tecnológica actual, hay otra discusión que afecta a 2E, no Plex, pero donde valen las opiniones de los participantes, ya que podrían asociarse sin mucha dificultad también a Plex: la complejidad de plataformas y tecnologías que deberían abarcarse hace difícil mantener el paso. En el caso de Office, el problema resulta aún más claro: los cambios de arquitectura ensayados por Microsoft son capaces de hundir a cientos de proveedores de servicios que trabajan para su plataforma (partners), como sucediera con el mercado de Silverlight, y seguramente con los incipientes desarrollos orietados al cuasi difunto Metro.
Otras discusiones de importancia vienen de la sección de Ideas, por ejemplo la postulación de la generación de servicios REST sobre el System i (discusión especialmente interesante), o las dos o tres referencias a la actalización del soporte de SQL en el System i (1, 2). O incluso las postulaciones a mejoras en el soporte de RPG ILE. Todos ellos hablan de un retraso de soporte a la evolución de las distintas plataformas, que resulta prioritario resolver. Hoy la evolución tecnológica es rápida y diversa, y resulta muy difícil abarcar el espectro completo de arquitecturas, tecnologías y paradigmas. Aún para el paradigma de diseño basado en modelos, resulta difícil seguir el paso para elaborar transformaciones adecuadas a cada caso y sus interrelaciones. ¿Qué camino es más aconsejable en éste caso, el de Plex?
Desde hace años, la solución de las transformaciones para atender nuevas áreas en Plex han estado a cargo de terceros; sea socios de negocios, como en el caso de los desarrollos web, telefonía móvil, e incipientemente cloud por parte de SoftDesign (Websydian) y CM First (WebClient), o los desarrollos para XML de Simon Jasperse, o los minipatterns debidos a Peter Fabel y Luwdig Hirth, o Stella Tools de George Jeffcock. Probablemente este sea el mejor modo de poder atender, especialmente sin un elevado presupuesto de investigación, la avasalladora ola de cambios en que nos movemos.
También desde hace años, el equipo de desarrollo de Plex expone crecientemente el API que permite la interrogación y operación del modelo, sus objetos y sus métodos. Es gracias a ésto que herramientas como Stella Tools puede trabajar. Probablemente esta vía sea la mejor para el desarrollo del modelador y sus generadores. Sería muy positivo que el trabajo del laboratorio de desarrollo de Plex se concentrara en éste aspecto: los modos para extender el modelador, para extender la inclusión de nuevos generadores que puedan ser elaborados por terceros. Estos terceros podrían ser empresas interesadas en extender la generación de código final a un nuevo área, o empresas interesadas en adecuar una extensión a sus propias necesidades. Al modo en que Xtext trabaja hoy como DSL. Creo que ésta es la salida viable de Plex en éste momento, y allí deberían centrarse los esfuerzos.
sábado, abril 26, 2014
A propósito de una API de c++
Hace algunos días me pidieron que estudiara alguna manera de validar que una fotografía cumplía con ciertos requisitos de densidad y medida en pixeles: un requerimiento simple, que exige acceder a metadatos de la imagen. Desde el punto de vista de nuestros modelos de Plex, esto significa usar un API, ya que no existen dentro del conjunto de funciones propias del producto, ni tampoco en ninguno de sus patrones de tecnología, alguna función preelaborada que permita obtener esa información.
Un API es un trozo de código específico de una plataforma que funciona encapsulado: en su interior resuelve una necesidad específica, en este caso, tratar metadatos de una imagen, intercambiando información con el modelo a través de parámetros. Así, el modelo se mantiene a nivel abstracto, y se relaciona con código específico de plataforma a través de un marco de inicialización que resuelve la relación entre el nivel del modelo y el del código encapsulado. El marco de las APIs que Plex maneja es relativo a plataformas específicas: c++ para clientes Windows de código no administrado (en términos del marco .NET) u ODBC, un motor de VBscript incrustado para VBscript, c# para .NET, y java o RPG para las variantes respectivas. Ya hace tiempo existe en la comunidad de Plex el estilo de definir un API de tal forma que responda a múltiples plataformas, por medio de metaoperaciones, que permitan intercambiar los parámetros entre el modelo y el código encapsulado, que será uno distinto por variante, y se resolverá en tiempo de compìlación según metaoperaciones que interroguen al modelo acerca de qué lenguaje se ha configurado. De esta forma, un sólo objeto API permite representar en un modelo su solución para tantas variantes como sea necesario y posible.
¿Estas son las únicas variantes posibles? Aunque hasta donde conozco, nadie lo ha intentado, existe una posibilidad de "sobrecargar" Plex para agregar APIs de otra plataforma o lenguaje: Plex sigue el modelo .COM, y permite importar un componente, y utilizar sus métodos y variables públicas como parte del modelo. Es entonces posible añadir transformaciones que habiliten otra variante, al menos al nivel puntual de una API. Utilizando elementos similares por otra vía, Websydian primero, y Webclient después, permitieron agregar capas de arquitectura web completas a un modelo de Plex.
Pero ahora, volviendo al pedido de lectura de metadatos de imágenes...Primero, restringimos el alcance del API a una aplicada a un modelo WinC, es decir, uno de plataforma Windows de modelo Win32, al menos para su primera versión: el horizonte de aplicación abarca por lo menos los próximos tres años. No está claro si en el futuro la aplicación continuará sobre Windows o Java, y en el primer caso, si sobre Win32 o WinRT. Digamos de todas formas que WinRT todavía no está soportado sobre Plex, lo que estrechaba el marco de posibilidades. Ahora bien, ¿qué alternativas hay disponibles para trabajar con imagenes escritas en c++ o c? En una primera revisión, encontré varias alternativas; Adobe XMP Toolkit, ExifTool (en modo de línea de comandos), Exiv2, y especialmente el Windows Imaging Component, o el objeto PropertyItem (en System.Drawing.Imaging Namespace) , ambos de Microsoft. Con algo de entusiasmo, comencé pesando las posibilidades de estas dos alternativas de Microsoft. Trabajando con Visual Studio y sobre una plataforma Windows ¿qué alternativa más "natural" puede considerarse que la del propietario de la plataforma? Sin embargo, luego de revisar la documentación (algo escasa en general), encuentré su uso demasiado exigente para el caso que debíamos atender: En primer lugar, la clase PropertyItem parecía más simple y directa de usar (a pesar de que tampoco estamos hablando de pocas líneas de código), pero aparecieron un par de observaciones (1, 2) que es necesario tener en cuenta, sin hablar de las posibles dependencias de versión del framework .NET. En el caso de WIC, examinando la documentación claramente marchabamos a matar moscas a cañonazos. Tanto por la complejidad relativa al objetivo a resolver, como también por la ambigua situación de evolución y deriva de .NET, Win32 y WinRT,decidí volver a evaluar otras opciones de código abierto, y finalmente adopté Exiv2, pero aún de una manera más simple: no recurriendo a la librería c++, sino usando el comando de consola exiv2, que permite acceder a la mayoría de los estándares de metadata...sin necesidad de asegurarse de que estén instalados los codecs adecuados...
En fin, resuelta la estrategia, en un par de días cerramos el problema con un código simple, reducido, y fácilmente ampliable a la obtención de otros atributos. En una situación de transición de la plataforma de Windows como la actual, es preferible quedar libre de dependencias y compromisos, si es posible. En tanto, ActiveX, VBA, VB for Office, c++ y en alguna medida .NET y .COM, atraviesan la borrosa frontera entre Win32, WinRT y otras alternativas que puedan sumarse a "un solo Windows"...
Un API es un trozo de código específico de una plataforma que funciona encapsulado: en su interior resuelve una necesidad específica, en este caso, tratar metadatos de una imagen, intercambiando información con el modelo a través de parámetros. Así, el modelo se mantiene a nivel abstracto, y se relaciona con código específico de plataforma a través de un marco de inicialización que resuelve la relación entre el nivel del modelo y el del código encapsulado. El marco de las APIs que Plex maneja es relativo a plataformas específicas: c++ para clientes Windows de código no administrado (en términos del marco .NET) u ODBC, un motor de VBscript incrustado para VBscript, c# para .NET, y java o RPG para las variantes respectivas. Ya hace tiempo existe en la comunidad de Plex el estilo de definir un API de tal forma que responda a múltiples plataformas, por medio de metaoperaciones, que permitan intercambiar los parámetros entre el modelo y el código encapsulado, que será uno distinto por variante, y se resolverá en tiempo de compìlación según metaoperaciones que interroguen al modelo acerca de qué lenguaje se ha configurado. De esta forma, un sólo objeto API permite representar en un modelo su solución para tantas variantes como sea necesario y posible.
¿Estas son las únicas variantes posibles? Aunque hasta donde conozco, nadie lo ha intentado, existe una posibilidad de "sobrecargar" Plex para agregar APIs de otra plataforma o lenguaje: Plex sigue el modelo .COM, y permite importar un componente, y utilizar sus métodos y variables públicas como parte del modelo. Es entonces posible añadir transformaciones que habiliten otra variante, al menos al nivel puntual de una API. Utilizando elementos similares por otra vía, Websydian primero, y Webclient después, permitieron agregar capas de arquitectura web completas a un modelo de Plex.
Pero ahora, volviendo al pedido de lectura de metadatos de imágenes...Primero, restringimos el alcance del API a una aplicada a un modelo WinC, es decir, uno de plataforma Windows de modelo Win32, al menos para su primera versión: el horizonte de aplicación abarca por lo menos los próximos tres años. No está claro si en el futuro la aplicación continuará sobre Windows o Java, y en el primer caso, si sobre Win32 o WinRT. Digamos de todas formas que WinRT todavía no está soportado sobre Plex, lo que estrechaba el marco de posibilidades. Ahora bien, ¿qué alternativas hay disponibles para trabajar con imagenes escritas en c++ o c? En una primera revisión, encontré varias alternativas; Adobe XMP Toolkit, ExifTool (en modo de línea de comandos), Exiv2, y especialmente el Windows Imaging Component, o el objeto PropertyItem (en System.Drawing.Imaging Namespace) , ambos de Microsoft. Con algo de entusiasmo, comencé pesando las posibilidades de estas dos alternativas de Microsoft. Trabajando con Visual Studio y sobre una plataforma Windows ¿qué alternativa más "natural" puede considerarse que la del propietario de la plataforma? Sin embargo, luego de revisar la documentación (algo escasa en general), encuentré su uso demasiado exigente para el caso que debíamos atender: En primer lugar, la clase PropertyItem parecía más simple y directa de usar (a pesar de que tampoco estamos hablando de pocas líneas de código), pero aparecieron un par de observaciones (1, 2) que es necesario tener en cuenta, sin hablar de las posibles dependencias de versión del framework .NET. En el caso de WIC, examinando la documentación claramente marchabamos a matar moscas a cañonazos. Tanto por la complejidad relativa al objetivo a resolver, como también por la ambigua situación de evolución y deriva de .NET, Win32 y WinRT,decidí volver a evaluar otras opciones de código abierto, y finalmente adopté Exiv2, pero aún de una manera más simple: no recurriendo a la librería c++, sino usando el comando de consola exiv2, que permite acceder a la mayoría de los estándares de metadata...sin necesidad de asegurarse de que estén instalados los codecs adecuados...
En fin, resuelta la estrategia, en un par de días cerramos el problema con un código simple, reducido, y fácilmente ampliable a la obtención de otros atributos. En una situación de transición de la plataforma de Windows como la actual, es preferible quedar libre de dependencias y compromisos, si es posible. En tanto, ActiveX, VBA, VB for Office, c++ y en alguna medida .NET y .COM, atraviesan la borrosa frontera entre Win32, WinRT y otras alternativas que puedan sumarse a "un solo Windows"...
domingo, marzo 16, 2014
Efectividad en aplicaciones móviles
Releyendo los 12 tips para crear un sitio móvil amigable (12 Tips for Creating a Mobile-Friendly Website) recomendados por Jennifer Lonoff Schiff en CIO...
Algunos de los tips son previsibles y conocidos, alguno difícilmente realizable (Don't go overboard with Java[...script?]; "consider replacing bulky JavaScript libraries like jQuery Mobile with standalone JavaScript"). Pero en conjunto, no deja de ser una buena guía.
Detrás de la simplicidad y síntesis requerida por una aplicación móvil hay un monto de trabajo y conceptualización superior al usual "en otras eras" del desarrollo de aplicaciones, particularmente basados en dos características especialmente dadas en ellas: la vida de una aplicación puede ser considerablemente corta, y debe prevenirse su visualización sobre un número alto de clientes, formados por dos dimensiones concurrentes de actores: sistemas operativos diversos, y visualizadores (browsers) diversos. Y las diferentes versiones de sistema operativo y visualizadores...Sólo puede salvarse de esta matriz de conformidad una empresa que desarrolle aplicaciones para su propio uso...y fuerce el uso de un producto y una versión.
¿Es posible encarar una serie de proyectos móviles sin contar con un marco de recursos que simplifique el trabajo de desarrollo?
Pero un marco tal, en muchos puntos entrará en conflicto con este tipo de recomendaciones, fundamentalmente aquellas que hacen a la construcción en sí misma. En mi caso, trabajando con plantillas de Webclient, existe una oportunidad de refactorización, en la propia capa intermedia. Webclient recurre a Dojo (aplicaciones web) o Sencha (aplicaciones móviles). Si bien técnicamente podría recurrir a javascript personalizado, mucho más económico y adaptado a la recomendación ("Avoid excessive JavaScript in your mobile websites where possible, because it runs differently across different browsers and devices," says Hume. "Even different models of the same phone can often behave quite differently when it comes to JavaScript"), esto requeriría algo así como reinventar la rueda, dedicando un tiempo precioso. Más económico es revisar las propias plantillas cuando resulte necesario, y buscar medios de simplificar su solicitud de servicios del marco Dojo/Sencha. Un compromiso entre resultado final y optimización.
Algunos de los tips son previsibles y conocidos, alguno difícilmente realizable (Don't go overboard with Java[...script?]; "consider replacing bulky JavaScript libraries like jQuery Mobile with standalone JavaScript"). Pero en conjunto, no deja de ser una buena guía.
Detrás de la simplicidad y síntesis requerida por una aplicación móvil hay un monto de trabajo y conceptualización superior al usual "en otras eras" del desarrollo de aplicaciones, particularmente basados en dos características especialmente dadas en ellas: la vida de una aplicación puede ser considerablemente corta, y debe prevenirse su visualización sobre un número alto de clientes, formados por dos dimensiones concurrentes de actores: sistemas operativos diversos, y visualizadores (browsers) diversos. Y las diferentes versiones de sistema operativo y visualizadores...Sólo puede salvarse de esta matriz de conformidad una empresa que desarrolle aplicaciones para su propio uso...y fuerce el uso de un producto y una versión.
¿Es posible encarar una serie de proyectos móviles sin contar con un marco de recursos que simplifique el trabajo de desarrollo?
Pero un marco tal, en muchos puntos entrará en conflicto con este tipo de recomendaciones, fundamentalmente aquellas que hacen a la construcción en sí misma. En mi caso, trabajando con plantillas de Webclient, existe una oportunidad de refactorización, en la propia capa intermedia. Webclient recurre a Dojo (aplicaciones web) o Sencha (aplicaciones móviles). Si bien técnicamente podría recurrir a javascript personalizado, mucho más económico y adaptado a la recomendación ("Avoid excessive JavaScript in your mobile websites where possible, because it runs differently across different browsers and devices," says Hume. "Even different models of the same phone can often behave quite differently when it comes to JavaScript"), esto requeriría algo así como reinventar la rueda, dedicando un tiempo precioso. Más económico es revisar las propias plantillas cuando resulte necesario, y buscar medios de simplificar su solicitud de servicios del marco Dojo/Sencha. Un compromiso entre resultado final y optimización.
domingo, julio 28, 2013
DSLs en su lugar
Una "vieja" entrada del blog de Bertrand Meyer, necesaria de recordar cuando se habla de DSLs (Domain Specific Languages) con alguna liberalidad: en ocasiones se los propone para resolver problemas específicos que parecen condenados a bufurcar el camino de trabajo. La posición de Meyer es radical: ¿cuándo crear un lenguaje de dominio? Nunca:
El contexto:
El contexto:
It is a common occurrence in software development. Someone says: “We should design a language”. The usual context is that some part of the development requires a rich functionality set, and it appears appropriate to provide a flexible solution through a specialized language.La objeción de Meyer:
Designing a language in such a context is almost always a bad idea (and I am not sure why I wrote “almost”). Languages are endless objects of discussion, usually on the least important aspects, which are also the most visible and those on which everyone has a strong opinion: concrete syntactic properties. People might pretend otherwise (“let’s not get bogged down on syntax, this is just one possible form”) but syntax is what the discussions will get bogged down to — keywords or symbols, this order or that order of operands, one instruction with several variants vs. several instructions… — at the expense of discussing the fundamental issues of functionality.Conclusión:
Worse yet, even if a language will be part of the solution it is usually just one facet to the solution.As was already explained in detail in [1], any useful functionality set will naturally be useful through several interfaces: a textual notation with concrete syntax may be one of them, but other possible ones include an API (Abstract Program Interface) for use from other software elements, a Graphical User Interface, a web user interface, yet another for web services (typically WSDL or some other XML or JSON format).
In such cases, starting with a concrete textual language is pretty silly, since it cannot yield the others directly (it would have to be parsed and further analyzed, which does not make sense). Of all the kinds of interface listed, the most fundamental one is the API: it describes the raw functionality, excluding any choice of syntax but including, thanks to contracts, elements of semantics.
One of the key rules for successful software construction — as for many other ventures of course, especially in science and technology — is to distinguish the essential from the auxiliary, and consequently to devote proper attention to the essential issues while avoiding disputations of auxiliary issues. To define functionality, API is essential; language is auxiliary.Si computaramos el tiempo de trabajo para definir el DSL y asegurar que funcione, en tales contextos, la adhesión a la posición de Meyer es segura...
So when should you design a language? Never. Well, hardly ever.
miércoles, agosto 29, 2012
Una presentación: Plex + Webclient
Una presentación publicada hoy por CM First, sobre PLex + Webclient. Para quienes no conocen Plex, una vista estimulante de sus posibilidades. Para quienes usan Plex y evalúan mover sus aplicaciones a nuevas arquitecturas, una idea de cómo mover aplicaciones a web + /o cloud +/o dispositivos móviles. Para quienes no conozcan Plex, es importante tener en cuenta la flexibilidad disponible en cuanto a arquitecturas.
En mi caso, este mes, testeando Plex + Android. Quizá agregue algunas líneas sobre sus resultados.
En mi caso, este mes, testeando Plex + Android. Quizá agregue algunas líneas sobre sus resultados.
sábado, junio 30, 2012
Stella Tools, actualización
Acabo de releer el artículo que le dedicara a Stella Tools, y creo que merece una actualización. Ya lo he hecho en el propio artículo, pero, para quienes no lleguen a el directamente, va este recordatorio: George Jeffcock, su autor, ha seguido trabajando en Stella, con gran aceptación de sus usuarios. Pero, lo más importante, ha creado una entrada en la Wiki de Plex, que puede constituír un buen punto de entrada para su uso y su entendimiento. Como se ha dicho antes, Stella es uno de los mejores ejemplos publicados y aprovechables de la potencia que ofrece el API del modelo de Plex. Nuevamente, estoy convencido de que, a partir del API del modelo, es posible extender Plex en amplios frentes.
Sobre este punto, Lee Dare ha escrito una introducción, y una descripción algo más amplia.
Sobre este punto, Lee Dare ha escrito una introducción, y una descripción algo más amplia.
Un tutorial sobre OCL
Jordi Cabot acaba de publicar una presentación sobre OCL (Object Constraint Language) que constituye un excelente tutorial sobre el metalenguaje. Creo que de lo que recuerdo, es el mejor. OCL es un conocido de todos cuantos hayan trabajado con UML en MDD, apreciado y criticado...El tutorial es muy útil para quienes estén tratando de ver el alcance del desarrollo por modelos, y ayuda claramente a entender cómo se pasa de un modelo visual a un cuerpo capaz de convertirse en código.
Desde el punto de vista de Plex, se puede decir sin dudas que el OCL tiene muchos puntos de contacto con el metalenguaje (metaoperaciones) que se puede utilizar en Plex para abstraer y extender el alcance de los modelos que se describan con la herramienta. Una mirada al tutorial, en nuestro caso, también es motivadora. Para recordar la potencia de las metaoperaciones.
Desde el punto de vista de Plex, se puede decir sin dudas que el OCL tiene muchos puntos de contacto con el metalenguaje (metaoperaciones) que se puede utilizar en Plex para abstraer y extender el alcance de los modelos que se describan con la herramienta. Una mirada al tutorial, en nuestro caso, también es motivadora. Para recordar la potencia de las metaoperaciones.
martes, octubre 25, 2011
A propósito de la década de Eclipse
Jean Bezivin comparte hoy en Google+ una nota de Ian Skerrett, de la Fundación Eclipse, que puntualiza algunos de sus logros en diez años de existencia. En lo esencial:
As I have written, Eclipse is celebrating 10 years of open source and community during the month of November. There have been a number of milestones that have shaped the Eclipse community but what have been the major accomplishments? What has Eclipse done to actually change the software industry? Here are what I see as some of the key accomplishments for Eclipse.De esto algo conocemos en la comunidad de Plex: al menos dos emprendimientos vinculan extensiones de Plex con las posibilidades de Eclipse: Webclient, creando una variante web ajax a partir de la generación de código Plex java, y el trabajo de Christopher Smith, mejorando el proceso de implementación de un modelo Plex. Dos sugerencias que abren un panorama más que positivo para el futuro.
1. Dominant Java IDE. Eclipse started out as being a really great Java IDE and continues today to be the market leader for Java IDEs. If you think back to the late 1990′s and early 2000′s the Java IDE market was a dog-fight between Borland JBuilder, Visual Cafe, IBM VisualAge for Java. Eclipse is now the clear leader and has approximately 65% market share in the Java IDE market.
2. De-facto Solution for C/C++ Tools. If you are building a tooling solution for C/C++ developers there is a very good chance you are using Eclipse CDT as the platform. In the realtime operating system and embedded development market, Eclipse CDT has become the de-facto standard. There at least 50 companies that are building their developer tools solution based on CDT.
3. A large and innovative modeling community. I am not sure how to quantify it but I believe the Eclipse modeling community has grown to become one of the largest and innovative communities at Eclipse. If you are doing modeling, chances are you are using Eclipse Modeling Framework (EMF). However, EMF is just the core that has created a really amazing community of innovation and diversity that happens at Eclipse Modeling. There are over 70 modeling projects at Eclipse and I know a lot more not hosted at Eclipse. It is a great success.
4. Integrating ALM Tools. The Mylyn project has grown into becoming the industry hub for integrating tools across the application lifecycle. There are now over 70 different Mylyn connectors that integrate different projects into the developer desktop.
5. Modular runtimes. Equinox and the EclipseRT projects demonstrate how modularity can work on a large scale. Everything at Eclipse is based on Equinox, since it is the OSGi runtime. However, Equinox and the EclipseRT top-level project has spawned an industry around Eclipse RCP and server-side OSGi. The range of applications being built on RCP is impressive, including NASA Mars Rover, financial institutions, aircraft design, genome decoding, etc, etc. On the server side, Equinox is used by most enterprise Java application servers and Virgo is emerging as a new Equinox based platform.
6. Eclipse Release Train. The Eclipse release trains have demonstrated open source communities can be predictable and scale to large distributed teams. This is incredibly important as large more conservative companies become involved in open source. Very few other organizations can claim a track record of predictability and scale that compares to the Eclipse community.
7. Eclipse Ecosystem. Eclipse has become one of the two major development tools platform in the industry; MS Visual Studio being the other. No matter what language you are using there is most likely an Eclipse IDE for you. No matter what developer tool you are using, there is probably an Eclipse plugin. No other platform has been able to create such a diverse and large ecosystem. It has actually made building and integrating developer tools a lot easier!
jueves, junio 23, 2011
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:
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.
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: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.
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.
- 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.
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.
viernes, septiembre 24, 2010
Oslo, último acto
Por primera vez, Charles Young, un usual sostenedor de las iniciativas de Microsoft, ha decidido hablar con crudeza acerca del anteúltimo proyecto de desarrollo de la empresa, Oslo, y sus productos asociados, Quadrant y M. En semanas pasadas, varios especialistas hablaron de la desaparición final del proyecto, desde hace ya algún tiempo reducido a producto de nicho, al pasar del ámbito general de Visual Studio al particular de SQL Server. Hasta ahora, sin embargo, había preferido considerar estas afirmaciones como conjeturas, no existiendo una palabra oficial. Pero ahora, Young, decepcionado, recoje palabras oficiales o casi, y esto sí significa un certificado de defunción. Defunción en segundas nupcias, ya que además de haber caído Oslo, ahora cae lo que queda en el proyecto SQL Server Modelling.
Así lo ve Young:
Quisiera aclarar que es lo particularmente incómodo de esta historia:
1) La dificultad en confiar en este tipo de proyectos: un largo período de tiempo empujando el mercado en un sentido, creando expectativas inútiles.
2) Relacionado con lo anterior, la ola de afirmaciones de entusiastas seguidores y partners acerca de la brillantez de un producto que nunca pasó de CTP (Community Technology Preview). Y esto, dicho sin medir el impacto que implica vender promesas sobre otros productos que tratan de hacerse duramente un lugar en el mercado.
Así lo ve Young:
RIP Quadrant. Adios, SSM RepositoryAtrás quedan las justificaciones (recordadas por Young) acerca del paso del proyecto Oslo al SQL Server Modelling, y no me queda duda que las palabras de Don Box corren el mismo camino que las de Douglas Purdy. Cómo cierra Box la historia de Oslo, Quadrant y M:
So it's official. Don Box has blogged an update on SQL Server Modelling. As widely rumoured, he has confirmed that Quadrant is dead. The shock is that the model repository has expired as well.
M is still hanging on in there, but we don't know anything more about what the future holds. For some time, the official word has been that it would arrive in conjunction with a future SQL Server release. I detect a possible change here, in that Don simply says 'We are continuing our investment in this technology and will share our plans for productization once they are concrete'. For my part, I maintain that tying 'M' to the SQL Server licence would be a really bad move. I know that every time Doug Purdy (who has recently left Microsoft to join Facebook) was challenged on this, he kept saying...no, SQL Server is a platform, not a product...watch this space. However, in the next breath it certainly sounded as if 'M' was in danger of being subsumed under a product license. No, no, no. Set it free to be used across Microsoft's platform. That platform is not SQL Server. It remains Windows, and for developers, it is Windows (on-premises and cloud) mediated through .NET.
We created the “Oslo” repository to make the model of a system or application easily accessible without relying on application-specific machinery to consume or query those models. The “Oslo” repository achieves this by storing the models for applications and systems in a shared SQL Server relational database.Dada la errática línea de investigación (si se puede hablar de ello), quizá haya que hacer apuestas sobre el futuro de estas nuevas, terceras afirmaciones sobre un mismo asunto.
Over the past year, we’ve gotten strong and consistent feedback from partners and customers indicating they prefer a more loosely-coupled approach; specifically, an approach based on a common protocol and data model rather than a common store. The momentum behind the Open Data Protocol (OData) and its underlying data model, Entity Data Model (EDM), shows that customers are acting on this preference.
Given the increasing adoption of both OData and EDM, we have decided to focus our investments in those technologies to make our modeling vision a reality. One important aspect of that focus is that we will not bring “Oslo” repository to market. We believe that taking a loosely coupled, federated approach using OData and EDM will ultimately get more models exposed sooner than an approach based on building a common repository database.
We created a visual tool codenamed “Quadrant” to help people query, update and visualize information that is stored in SQL Server databases. As with the “Oslo” repository, customers told us that they wanted to work with information from a variety of sources, not just data stored in an RDBMS. Customers also told us that they wanted the experience to be native to the tools they are already using; specifically either Visual Studio or Microsoft Office. Given this feedback, we are not bringing “Quadrant” to market. Instead, we will work to make the experience with OData and EDM in Visual Studio and Microsoft Office even better.
Finally, we created a language codenamed “M” for defining schema, constraints, queries, and transformations. While we used “M” to build the “Oslo” repository and “Quadrant,” there has been significant interest both inside and outside of Microsoft in using “M” for other applications. We are continuing our investment in this technology and will share our plans for productization once they are concrete.
Quisiera aclarar que es lo particularmente incómodo de esta historia:
1) La dificultad en confiar en este tipo de proyectos: un largo período de tiempo empujando el mercado en un sentido, creando expectativas inútiles.
2) Relacionado con lo anterior, la ola de afirmaciones de entusiastas seguidores y partners acerca de la brillantez de un producto que nunca pasó de CTP (Community Technology Preview). Y esto, dicho sin medir el impacto que implica vender promesas sobre otros productos que tratan de hacerse duramente un lugar en el mercado.
domingo, agosto 29, 2010
El modelo de Eclipse + Plex... ¿+ Xtext?
Varios meses muy atareado. Vuelvo de dos semanas de vacaciones, y llega el momento de rematar el trabajo...Extendiendo dos modelos construídos con Plex, con una presentación basada en C++ y servicios llamados en iSeries-RPG400/RPGIV, para que puedan disponer una presentación Web. La parte Web, hecha con Webclient (ADC Austin), con su extensión Java/Javascript disparada a través del uso de Eclipse. Este es el segundo proyecto organizado fuera de CA usando Eclipse como un mediador para extender Plex (el primero, el open source encarado por Christopher Smith para usar las facilidades de test y depuración de Eclipse/java con Plex).
En fin, el proyecto funciona...A partir de los modelos diseñados para C++/RPG, creamos una variante Java-WebClient que separa el diseño de paneles (y reportes) en la variante, de tal forma que conviven en el mismo modelo dos paneles distintos; con sólo configurar una variante u otra, generamos paneles para cada lenguaje. La lógica la hemos desarrollado en la variante base (C++), usando metaoperaciones para separar las diferencias de implementación entre ambos lenguajes. Luego, el modelo declara en la variante Java-Web dos elementos: nueva herencia que indica qué tipo de paneles Web se construirán, y el lenguaje Java de implementación.Así, se genera distinto código según la variante configurada.
¿Cómo pasa el código de Plex a Eclipse? El código Java generado en Plex es tomado por scripts escritos en Ant y transferido a un proyecto JEE en Eclipse. El área de trabajo en Eclipse se compone de un proyecto Ant , uno Java, un servlet WebClient, y un proyecto Web (JEE). Por cada panel el proyecto java construye una función (servlet) que enlaza la presentación y los eventos interactivos con el código Javascript que ejecutará en tiempo real. El código javascript (Dojo + Json) está enlazado a plantillas tipo que son invocadas al indicarle al modelo que se hereda de determinados patrones Webclient.
Teóricamente, (y lo he puesto en práctica rudimentariamente) cada plantilla es factible de ser creada por el modelador. Mientras nos familiarizamos, nos hemos sujetado a utilizar las que están disponibles, modificando algunos aspectos de éstas, sea en las directivas de las plantillas o en las hojas de estilo asociadas.
El último paso es configurar los ficheros properties y adecuar el fichero de configuración de la aplicación Web (Web.xml), crear un paquete War, e implementarlo en Websphere (este paso resultó sorprendentemente más fácil de hacer de lo que esperaba).
Es decir, Plex es extendido en este caso agregando enteramente el código Ajax en un proyecto Eclipse, y asociándolo con el código Plex java mediante un servlet. Así, no sólo extendemos Plex a aplicaciones Web que se basan en Ajax, sino que podemos usar las facilidades de testeo y depuración de Eclipse: en una sesión normal, testeo el código java directamente en el ambiente Eclipse, y, usando Tomcat o Jetty, el código Web. Si hay diferencias de comportamiento, a revisar...(Consola de Java, Log de actividad del servlet).
Generalizando, la utilización de Eclipse por distintos grupos de desarrollos de Plex, puntualiza la potencia disponible a partir de esta combinación. Existen infinitos recursos disponibles en Eclipse, particularmente el Eclipse Modeling Framework, y las extensiones que lo utilizan (UML2, OCL). Aquí se ha mencionado a MODISCO (Model Discovery), como un elemento de mucho interés que debería ser seguido con atención. Y otro más debería ser seguido con máximo interés: Xtext, que por su versatilidad podría ser usado para extender Plex de muy distintas maneras.
Es mi parecer, y ojalá estuviera en mis posibilidades explorarlo, que es posible extender Plex para muy distintos alcances, entre ellos algunos que en más de una oportunidad fueron desestimados basados en el alcance estricto de sus generadores.
A modo de confirmación, dos discusiones (1,2) de finales de este mes muestran que es posible incluír IPhone o IPad entre las aplicaciones generables a partir de modelos Plex.
En fin, el proyecto funciona...A partir de los modelos diseñados para C++/RPG, creamos una variante Java-WebClient que separa el diseño de paneles (y reportes) en la variante, de tal forma que conviven en el mismo modelo dos paneles distintos; con sólo configurar una variante u otra, generamos paneles para cada lenguaje. La lógica la hemos desarrollado en la variante base (C++), usando metaoperaciones para separar las diferencias de implementación entre ambos lenguajes. Luego, el modelo declara en la variante Java-Web dos elementos: nueva herencia que indica qué tipo de paneles Web se construirán, y el lenguaje Java de implementación.Así, se genera distinto código según la variante configurada.
¿Cómo pasa el código de Plex a Eclipse? El código Java generado en Plex es tomado por scripts escritos en Ant y transferido a un proyecto JEE en Eclipse. El área de trabajo en Eclipse se compone de un proyecto Ant , uno Java, un servlet WebClient, y un proyecto Web (JEE). Por cada panel el proyecto java construye una función (servlet) que enlaza la presentación y los eventos interactivos con el código Javascript que ejecutará en tiempo real. El código javascript (Dojo + Json) está enlazado a plantillas tipo que son invocadas al indicarle al modelo que se hereda de determinados patrones Webclient.
Teóricamente, (y lo he puesto en práctica rudimentariamente) cada plantilla es factible de ser creada por el modelador. Mientras nos familiarizamos, nos hemos sujetado a utilizar las que están disponibles, modificando algunos aspectos de éstas, sea en las directivas de las plantillas o en las hojas de estilo asociadas.
El último paso es configurar los ficheros properties y adecuar el fichero de configuración de la aplicación Web (Web.xml), crear un paquete War, e implementarlo en Websphere (este paso resultó sorprendentemente más fácil de hacer de lo que esperaba).
Es decir, Plex es extendido en este caso agregando enteramente el código Ajax en un proyecto Eclipse, y asociándolo con el código Plex java mediante un servlet. Así, no sólo extendemos Plex a aplicaciones Web que se basan en Ajax, sino que podemos usar las facilidades de testeo y depuración de Eclipse: en una sesión normal, testeo el código java directamente en el ambiente Eclipse, y, usando Tomcat o Jetty, el código Web. Si hay diferencias de comportamiento, a revisar...(Consola de Java, Log de actividad del servlet).
Generalizando, la utilización de Eclipse por distintos grupos de desarrollos de Plex, puntualiza la potencia disponible a partir de esta combinación. Existen infinitos recursos disponibles en Eclipse, particularmente el Eclipse Modeling Framework, y las extensiones que lo utilizan (UML2, OCL). Aquí se ha mencionado a MODISCO (Model Discovery), como un elemento de mucho interés que debería ser seguido con atención. Y otro más debería ser seguido con máximo interés: Xtext, que por su versatilidad podría ser usado para extender Plex de muy distintas maneras.
Es mi parecer, y ojalá estuviera en mis posibilidades explorarlo, que es posible extender Plex para muy distintos alcances, entre ellos algunos que en más de una oportunidad fueron desestimados basados en el alcance estricto de sus generadores.
A modo de confirmación, dos discusiones (1,2) de finales de este mes muestran que es posible incluír IPhone o IPad entre las aplicaciones generables a partir de modelos Plex.
lunes, junio 14, 2010
La supuesta muerte del RPG
Bob Cozzi conversa sobre la enésima vez que se ha hablado de la muerte del RPG. Cada año, el "ultimo grito de la programación" crea una nueva estrella, pero pasan los años, y los más robustos siguen quedando...
Claramente, el problema no está en los lenguajes: para el RPG mismo, existen distintas variantes de generadores de código que intermedian la relación con el código. La gran variedad de lenguajes que proliferan aceleran la presencia de otro nivel de herramientas, capaces de superar la diversidad, y de articular lo mejor de cada uno de ellos: los que permiten el desarrollo basado en modelos, plantillas, metadeclaraciones, según el sabor de cada uno. Lejos está la época en que una aplicación podía basarse en un sólo lenguaje, en un solo hardware, y en una sola empresa. Para la etapa presente de la tecnología, el punto de vista debe estar un escalón por encima de cada lenguaje.
"I have been writing RPG longer than some of you reading this have been alive. One recurring theme that occurs every seven or eight years is the infamous "RPG is dead" theme. Still, here we are in 2010 writing new applications in RPG IV—many of which will probably be running 30 years from now." (...) At that point in time, the C language was becoming very popular in college and university and we started to hear how RPG programmers should start learning C, or they would have no future. A few years later C++ was all the rage, and we heard the same line of advice about it related to RPG III, blah, blah, blah.RPG está atado al futuro del ISeries (o AS400). Sólidamente integrado al sistema operativo, durará tanto como dure el ISeries. El RPG es capaz de sacar del ISeries lo mejor suyo. ¿Y cuánto durará éste? Por ahora, parecería que ni IBM puede matarlo...The one consistent theme that helps push people to another programming language or application architecture is interface. When RPG III supported the 5250 devices better than anything else, people moved to it. C and C++ didn't really bring anything new to the midrange user interface table except an antiquated teletype output capability. So unless you were writing system-level code, midrange programmers ignored C and C++. Today, I use C for low-level routines or when RPG IV can't handle it. It is rare that I can't do something in RPG IV, but it's good to know that I can "drop into" C, or better yet, C++ when I need to.
Java was also largely ignored by the vast majority of midrange programmers. An infamous "vocal few" did evangelize Java to i shops, but it really doesn't provide any new interface capabilities beyond what could already be done with native RPG and DDS or the growing list of OS/400 APIs. So while Java adoption has found its way into a relatively large percentage of midrange shops, and many of those shops have at least one Java programmer, in many cases if a shop has moved entirely to Java, it subsequently moved off this operating system platform and onto lower-cost Intel/Linux or even WinTel solutions.
One cool thing I enjoy using Java for is "Internet CL." I use Java like CL when web or Internet work needs to be done, such as the SendMail application or the POI interface. Again, interface is key to the success of the implementation. In these two situations Java does something we can't easily do with RPG IV and traditional APIs. So Java should be used. Another use is cross-platform support. Perhaps even better than C, Java brags about being cross-platform independent, and largely it is. So if you have one of those third-party code generators, query tools, or report writers that generate Java (such as the hugely popular mPower from mrc), you're one step ahead of creating a catalog of platform-independent solutions.
Claramente, el problema no está en los lenguajes: para el RPG mismo, existen distintas variantes de generadores de código que intermedian la relación con el código. La gran variedad de lenguajes que proliferan aceleran la presencia de otro nivel de herramientas, capaces de superar la diversidad, y de articular lo mejor de cada uno de ellos: los que permiten el desarrollo basado en modelos, plantillas, metadeclaraciones, según el sabor de cada uno. Lejos está la época en que una aplicación podía basarse en un sólo lenguaje, en un solo hardware, y en una sola empresa. Para la etapa presente de la tecnología, el punto de vista debe estar un escalón por encima de cada lenguaje.
domingo, mayo 02, 2010
Conversando sobre Essential
Este pasado miércoles, en el marco de la Semana Informática, por fin pude acercarme a una presentación de Pedro Molina sobre Essential, su editor orientado al trabajo con modelos y metamodelos. Fue muy útil verlo en acción, aplicado a un caso específico de cierta complejidad. El resultado fue que me comprometiera a dedicarle tiempo para testearlo.
En el marco de una presentación más amplia junto a su colega de Capgemini Nicolás Cornaglia, que explicaba las características del framework basado en java que suele utilizar, ambos aplicaron Essential a la especificación del modelo que describían. Visto a través de la demostración, da buena impresión, y me sugirió ideas acerca de cómo usarlo. Veremos en las próximas semanas, si es posible.
Sobre Essential, dice Pedro (1, 2) :
En el marco de una presentación más amplia junto a su colega de Capgemini Nicolás Cornaglia, que explicaba las características del framework basado en java que suele utilizar, ambos aplicaron Essential a la especificación del modelo que describían. Visto a través de la demostración, da buena impresión, y me sugirió ideas acerca de cómo usarlo. Veremos en las próximas semanas, si es posible.
Sobre Essential, dice Pedro (1, 2) :
En respuesta a una pregunta de Ron Kersic, Pedro aclara que Essential está construído con .NET 3.5 y MGrammar. Francamente, la vista de la herramienta es limpia y clara.Essential is a project to create a workbench for applying Model Driven Development (MDD).
The workbench allows to experiment with models, metamodels, templates and transformations in an integrated environment.
The main focus is to provide a declarative environment oriented to prototyping and evolving custom DSL and MDD tools in a quick and clean way.
The goals of the project are following ones:
- to declaratively describe metamodels, models, templates, and transformations using textual DSLs
- to provide a comfortable editor for each of these four pillars,
- to provide model checkers to assure the integrity of the four, and
- to build code generators and transformation interpreters to achieve the output we are looking for.
lunes, abril 19, 2010
Un caso de uso de desarrollo basado en modelos
Fred Madiot publicó hace pocos días una breve reseña del paso a diseño basado por modelos en un caso práctico: un banco tunecino que decide reelaborar sus aplicaciones cambiando tecnología y método de construcción. Nada mejor que casos prácticos para que quienes se aproximan a conocer el desarrollo basado en modelos, tengan una idea del estilo y posibilidades de MDD.
Para mi experiencia y preferencias, de todas formas esperaría que cada caso (aquí, el proyecto del banco) requiriera menos elaboración (me refiero a que el modelado se centrara más en la aplicación, y no inicialmente en la herramienta de transformaciones), y que el código se derivara sin fase final manual, desde un generador bajo Eclipse:
En común: en la comunidad de Plex, la importancia de Eclipse como puente entre las reglas de Plex y el ancho mundo de los metamodelos para resolver lo que no esté contemplado.
Fred Madiot también participa del proyecto MoDisco, que intenta desarrollar herramientas capaces de extraer el modelo implícito en una aplicación antigua (Legacy Reverse Engineering), de lo que hemos hablado en alguna oportunidad.
Para mi experiencia y preferencias, de todas formas esperaría que cada caso (aquí, el proyecto del banco) requiriera menos elaboración (me refiero a que el modelado se centrara más en la aplicación, y no inicialmente en la herramienta de transformaciones), y que el código se derivara sin fase final manual, desde un generador bajo Eclipse:
From the EMF model of the reference application, the templates have regenerated 6 MXML files and 19 ActionScript files (Commands, Events, Service Delegates, Front Controller, and Value Objects). The MXML files contain the graphical definition of the GUI: they will be generated only once, just to provide a first application which can be executed. Then they will be edited and maintained with a WYSIWYG designer.Este aspecto revela en mi criterio la todavía relativa inmadurez de las herramientas disponibles. Digo esto desde mi punto de vista, con una herramienta, Plex, que considero más consistente en este terreno, y a la vez menos flexible en el mismo aspecto que estoy observando.
En común: en la comunidad de Plex, la importancia de Eclipse como puente entre las reglas de Plex y el ancho mundo de los metamodelos para resolver lo que no esté contemplado.
Fred Madiot también participa del proyecto MoDisco, que intenta desarrollar herramientas capaces de extraer el modelo implícito en una aplicación antigua (Legacy Reverse Engineering), de lo que hemos hablado en alguna oportunidad.
lunes, marzo 22, 2010
AJGenesis
El proyecto de Angel J López evoluciona desde hace casi tres años, cuando por primera vez comenté algo sobre su proyecto. Aparece ahora mas completo, y, por lo que sigo, activo y trabajando:
AjGenesis is an open software project, that generates any text artifact, starting from free Models and Templates. You can define your own models and templates, they aren't fixed or predefined. This capability gives you lot of flexibility. The examples generates Java, JSP, ASP.NET, VB.NET, C Sharp, PHP. The examples generate code for entities, pages, solution and project files, store procedures, DDL scripts, elements for Domain-Driven Design, and more...Su proyecto no sólo puede ser muy útil, sino que también es motivador de ideas para extender el uso de modelos. Para visitar, estudiar, y si cabe, usar.
domingo, diciembre 13, 2009
Una discusión en LinkedIn sobre el alcance de MDD/MDA
Algunos días atrás se mencionó aquí una discusión en LinkedIn sobre MDD, que criticaba el valor del concepto. Algunos de los cuestionamientos no parecían estar adecuadamente orientados. Sin embargo, las respuestas generadas sí aportan elementos importantes sobre la relevancia del desarrollo basado en modelos, sea que se hable de modelos genéricos o modelos específicos de dominio. En términos generales, lo que sigue es lo más relevante de la conversación:
Cuestionamiento de la portabilidad de los modelos:
Finalmente, dos aspectos defendidos por dos de los participantes merecen destacarse:
Rui Curado afirma:
Para quienes sean miembros de LinkedIn, la dirección de la discusión, aquí.
Cuestionamiento de la portabilidad de los modelos:
(...) until recently the only choices for these modelling languages were proprietary. So by using MDD not only were you choosing to use an obscure programming language with no published standard, you were locking yourself into the only proprietary tool that implemented it. These days its not so bad; there are open source MDD tools. But as far as I know there is no formal standard for the modelling language, which makes the portability of your model between tools effectively zero. This is ironic, given that portability is supposed to be one of the big advantages of MDD.Este punto es particularmente observable, ya que MDD (y aún DSM) están lejos de ser cerrados, aún tratándose de lenguajes de modelado propietarios. Si sobre algo se ha trabajado en años recientes, es sobre interoperabilidad y metamodelos. Pensando en su visión enfocada en DSLs, Juha-Pekka Tolvanen contesta:
Based on my experience in hundreds of cases, MDD makes always sense when we can raise the level of abstraction with models above the code. In other words, the use of class diagram to represent a class with a rectangle symbol in order to generate a class in file makes very little sense! People who have tried this - usually with some UML tools - are obviously disappointed.Cuestionamiento a la productividad:
In order to raise the level of abstraction we usually need domain-specific concepts - often implemented into a language and supported by some tool. Luckily the metamodel-based tools that allow to define own languages are always ‘open’ in that respect that while they allow to define code generators (or have API, XML format etc for interchange) they always allow you to move your models to other similar tools too. So there is no locking as you described and there are even published bridges among metatools. IMHO: (and I work for a tool vendor) you should always choose a tool that allows you to move your data (models and metamodels) to other tools - if you don’t do that you have the lock problem you mentioned.
First, to those who point to practical experience [...]: a "successful" project, at best, just means it it was delivered within the estimated budget and timescale (at worst it means a failure that was declared a success for political reasons). The real question is: does MDD deliver projects that cost less and take less time than any of the alternatives. I can have a successful project using assembler, provided I have the budget and time. So: do you have evidence comparing like-for-like that MDD costs less, and if so by how much?A este respecto, Juha-Pekka Tolvanen, con gran experiencia en lenguajes específicos de dominio, responde acudiendo a experiencias bien conocidas:
I have only seen one study for MDD (which I can't locate right now) that found MDD development was 40% cheaper than conventional development. However that only compared two development teams, and so could easily have been due to random variation. Furthermore just using a higher level language can give even bigger savings. A study by Lutz Prechelt http://page.mi.fu-berlin.de/prechelt/Biblio//jccpprtTR.pdf gives a clear view of the range available both in developer ability and programming language. Ulf Wiger found that Erlang quadrupled productivity over C++, and the sparse evidence available suggests that Haskell is even more productive.
[Acerca de la observación sobre productividad] (“does MDD projects cost less and take less time”) is obviously difficult to answer in general since there are so many modeling languages and programming languages to compare. Ultimately it depends on how well the languages compared fit to the particular problem to be solved.Y Mark Dalgarno, basándose en las experiencias volcadas en las conferencias de Code Generation, responde:
Since evaluating even two alternatives takes a lot of resources with a proper research method, companies usually don’t make detailed evaluation or at least do not publish them. Fortunately, some do. For example, Panasonic implemented the same system twice and reported 500% productivity improvement when comparing "MDD" to traditional manual coding in C (see http://www.dsmforum.org/events/DSM07/papers/safa.pdf). Polar arranged a laboratory study and a pilot project measuring at least 750% productivity (see http://www.dsmforum.org/events/DSM09/Papers/Karna.pdf). Similar significantly gains are reported by companies like Nokia, Lucent, EADS and Siemens which have defined their own domain-specific modeling languages along with code generators. You can check cases on using Domain-Specific Modeling from http://www.dsmforum.org/cases.html and if you want to see example languages on various domains, check http://www.metacase.com/cases/dsm_examples.html.
These above mentioned productivity figures are quite different than 40% mentioned. I would guess that they used a modeling language that only slightly raises the level of abstraction. Paul, can you find the reference for that case? We have been trying to collect reported cases over the years and this would be valuable addition.
The Code Generation conference has documented MDD success stories in the following domains:(Se podría agregar a la contestación de Mark, que, más aún, sería indudablemente posible crear modelos que generasen código con los lenguajes de alto nivel sugeridos como "reemplazo" de los modeladores). Este punto particularmente muestra que el cuestionamiento parte de una base errónea.
Financial trading platforms
Administrative enterprise applications
Grid & Cloud applications
JEE enterprise applications
Control & Data acquistion systems
Simulation & Training systems
User interface generation
Mobile device applications
Insurance applications
Telecomms applications
Home automation systems
Business and organisational workflow applications
Technology platform migration
Security policy management
Legacy application modernization
Defence systems
Web applications
Hiding framework complexity, handling multiple frameworks
Middleware applications
Sensor Systems
This is by no means the limit of MDD potential.
HLLs (including the ones you list) only allow you to raise your abstraction level so far and it still seems that where MDD is applicable it can outperform HLL by an order of magnitude in terms of productivity depending on the problem domain.
Finalmente, dos aspectos defendidos por dos de los participantes merecen destacarse:
Rui Curado afirma:
MDD, with proper tool support, gives you additional benefits like traceability, automation, collective knowledge sharing.Andrea Rocchini pone en el centro de la discusión lo mejor de MDD:
The real advantage of MDD is defining a problem/application with semantic rather than procedural flow.
A model contain all and only the relevant information about problem; it's totally decoupled from implementing technology.
A model can be transformed/interpreted with many tools and many patterns, now and in the future.
From a model we can produce many kind of entity: applications (for many platform), documentation, simulation processes, ...
A model could be designed by an expert of the domain problem rather than a programmer (an expert of IT technology ...)
A procedural flow in a programming language instead is a monolithic object; it's not much recyclable, is strongly technology dependant, conceptual design and implementation are mixed.
The necessary knowledge to have for developing a modern application is all-changing and every day growing.
All that is very frustrating.
Naturally the MDD approach is less free and result depend on quality of tool/interpreter.
Para quienes sean miembros de LinkedIn, la dirección de la discusión, aquí.
martes, junio 23, 2009
Plex y el concepto de Model Discovery
Pedro Molina comenta en su blog la intervención de Stuart Kent en CodeGeneration 2009, explicando las características del Visual Studio Team System para la reingeniería de aplicaciones (Model Discovery):
El problema de la ingeniería reversa de aplicaciones antiguas es complejo, y merece que le dediquemos en algún momento tiempo aparte. Y dadas las complejas posibilidades del entramado de software que cualquier organización encara hoy, atender a sus características y pensar el escenario debiera tener tiempo reservado.
Pero esta nota es para recordar, a propósito de MoDisco, que Plex dispone de una herramienta para facilitar el paso de aplicaciones antiguas a Plex, el Application Generator. Esto es de interés especialmente para quienes lo usan, que no siempre conocen este agregado, para quienes estudian pasar de 2E a Plex, o para quienes buscan una vía de modernización.
¿Cuál es el alcance de esta herramienta? Vale como un auxiliar, básicamente para el reconocimiento del esquema de la base de datos subyacente, y parcialmente para la importación de programas a un modelo Plex. Sólo es aplicable en tres escenarios: un conjunto de tablas posibles de tratar con ODBC, una base de datos DB2 en ISeries, o un subconjunto de este caso, que es un modelo 2E. En el caso de ODBC se pueden importar las definiciones y relaciones entre tablas, y en los otros dos casos se agregan a esta recuperación mínima, la obtención de los programas que manipulan estas tablas. La importación en este caso será como objetos de tipo API, cuyo comportamiento interno se desconoce, pero se exponen al modelo los parámetros que mantiene cada función. La importación no es directa, sino a un estadio intermedio (un repositorio) que es posible modificar, y al que se le puede aplicar herencia, a nivel de cada objeto identificado. La herencia se hace a partir de objetos del modelo al que se importará, con lo que es posible adaptar los objetos antiguos al modelo nuevo.
¿Es esto suficiente? No, evidentemente: un programa importado, al ser una "caja negra", es en realidad un objeto transitorio, que debería reinterpretarse en el nuevo modelo, o permanecer invariable. Este esquema es útil para quien evolucione el antiguo modelo, pasando por una transición manejada.
¿Es posible mejorarlo? Aquí entran las ideas de MoDisco, que parte de una base que es extensible, lo que pudiera abrir posibilides de elaborar herramientas aplicables a modelos Plex. Dado el creciente interés de la comunidad de usuarios de Plex por Eclipse, quizá esto no sea imposible.
¿Qué mejoras esperaría? Ahí caemos a las necesidades usuales en un proceso de ingeniería reversa de un viejo sistema. Y como esto es más general, como se ha dicho, vale la pena verlo aparte, en otro momento. Así será.
These tools are capable of selecting the source code of a solution and search for all the dependencies in the code. The tools produces an XML graph with the dependences and Visual Studio is able to draw them (a la Graphviz) and do drilldown from assemblies to namespaces, classes & methods.Hace pocos días se mencionó aquí otro caso, sumamente interesante, por su capacidad de extensión, Modisco. Este conjunto de herramientas está aún en desarrollo, pero apunta en la dirección de mayor interés, que es no sólo descubrir la arquitectura y la lógica de una aplicación antigua y probablemente no documentada, sino también desplegarla en un contexto nuevo, preparada para ser repensada sobre nuevas bases, las que aquí se proponen siempre. Un salto que implica salir de un conjunto de difícil mantenimiento, de conocimiento incierto, a un modelo capaz de ser mantenido, evolucionado, transportado y articulado entre distintas plataformas.
I had to do this manually once: looking for cross references in more than 2.500 mini-applications of legacy code and finished it finally doing some kind of regex searching for the references, creating a text based graph and display it all with the quoted library GraphViz and some clustering techniques.
El problema de la ingeniería reversa de aplicaciones antiguas es complejo, y merece que le dediquemos en algún momento tiempo aparte. Y dadas las complejas posibilidades del entramado de software que cualquier organización encara hoy, atender a sus características y pensar el escenario debiera tener tiempo reservado.
Pero esta nota es para recordar, a propósito de MoDisco, que Plex dispone de una herramienta para facilitar el paso de aplicaciones antiguas a Plex, el Application Generator. Esto es de interés especialmente para quienes lo usan, que no siempre conocen este agregado, para quienes estudian pasar de 2E a Plex, o para quienes buscan una vía de modernización.
¿Cuál es el alcance de esta herramienta? Vale como un auxiliar, básicamente para el reconocimiento del esquema de la base de datos subyacente, y parcialmente para la importación de programas a un modelo Plex. Sólo es aplicable en tres escenarios: un conjunto de tablas posibles de tratar con ODBC, una base de datos DB2 en ISeries, o un subconjunto de este caso, que es un modelo 2E. En el caso de ODBC se pueden importar las definiciones y relaciones entre tablas, y en los otros dos casos se agregan a esta recuperación mínima, la obtención de los programas que manipulan estas tablas. La importación en este caso será como objetos de tipo API, cuyo comportamiento interno se desconoce, pero se exponen al modelo los parámetros que mantiene cada función. La importación no es directa, sino a un estadio intermedio (un repositorio) que es posible modificar, y al que se le puede aplicar herencia, a nivel de cada objeto identificado. La herencia se hace a partir de objetos del modelo al que se importará, con lo que es posible adaptar los objetos antiguos al modelo nuevo.
¿Es esto suficiente? No, evidentemente: un programa importado, al ser una "caja negra", es en realidad un objeto transitorio, que debería reinterpretarse en el nuevo modelo, o permanecer invariable. Este esquema es útil para quien evolucione el antiguo modelo, pasando por una transición manejada.
¿Es posible mejorarlo? Aquí entran las ideas de MoDisco, que parte de una base que es extensible, lo que pudiera abrir posibilides de elaborar herramientas aplicables a modelos Plex. Dado el creciente interés de la comunidad de usuarios de Plex por Eclipse, quizá esto no sea imposible.
¿Qué mejoras esperaría? Ahí caemos a las necesidades usuales en un proceso de ingeniería reversa de un viejo sistema. Y como esto es más general, como se ha dicho, vale la pena verlo aparte, en otro momento. Así será.
lunes, junio 15, 2009
MoDisco: Ingeniería reversa guiada por modelos
Jean Bézivin, a quien se ha recordado aquí más de una vez, promueve y participa en un proyecto de especial interés: MoDisco ( abreviando Model Discovery), que se propone la extracción de modelos partiendo del análisis de sistemas antiguos (legacy systems). A mi juicio, este es un movimiento de importancia en el camino de avanzar hacia aplicaciones basadas en modelos: Si se examina la realidad del uso de sistemas informáticos, el panorama deja una gran heterogeneidad, un gran volúmen de sistemas obsoletos, y una débil penetración de estos conceptos, que dominan las actividades de grupos académicos y conferencias, pero que representan un porcentaje bajo del modo en que se construyen las aplicaciones en el mundo real. Si tomamos las búsquedas laborales, los ránkings de uso de lenguajes, lo que se entrevé de la vida diaria, encontramos un extenso uso de lenguajes de tercera generación, comenzando por COBOL (especialmente en España), RPG, Visual Basic, Java, C, C++...Una coexistencia de viejas aplicaciones que no se tocan porque funcionan, con modernos intentos cubriendo aspectos parciales, o viceversa, modernos paquetes preplaneados que integran antiguos desarrollos.
Por tanto, una herramienta que partiendo de lo que existe, permite crear un marco de abstracción adecuado para encauzar la construcción de software, abre posibilidades de facilitar la ampliación del uso de mejores herramientas, acortando el camino entre el desarrollo basado en modelos y las aplicaciones existentes. Como siempre se ha destacado aquí, manejar la construcción de las aplicaciones desde la abstracción de un modelo es la manera de superar esta compleja coexistencia que inevitablemente se dará en la vida real.
En fin, el objetivo de MODISCO es facilitar un puente hacia este terreno.
De la presentación del proyecto:
MoDisco (for Model Discovery) is an Eclipse-GMT project for model-driven reverse engineering. The objective is to allow practical extractions of models from legacy systems. Because of the widely different nature and technological heterogeneity of legacy systems, there are several different ways to extract models from such systems. MoDisco proposes a generic and extensible metamodel-driven approach to model discovery. A basic framework and a set of guidelines are provided to the Eclipse contributors to bring their own solutions to discover models in various kinds of legacy.Sobre la importancia de su enfoque para hacer ingeniería reversa de antiguos sistemas, dice su presentación:
Una característica (propia de Eclipse) es su característica de ser extensible, lo que deja abierta la posibilidad de adecuarlo a diferentes requerimientos a partir de su núcleo.What are the benefits of the MoDisco approach compared to already existing reverse engineering tools?
First, MoDisco proposes a unified approach to model-driven reverse engineering and a metamodel driven methodology. This way, we are able to work in the modeling world, coming from a heterogeneous world to a homogeneous one. The target model engineering space already proved its adaptability and scalability by several experiments to match requirements for data integration, tools interoperability and platform migration.
Moreover, the well structured modeling world allows easy manipulation of many different concepts in a unified way. For instance, every model can be transformed, weaved, extracted with the same tool set. As those operations are defined upon models’ metamodels, they are reusable for different use cases.
The MoDisco framework is a generic framework that provides a basis for extension. It offers a minimum tool set to allow model discovery. The first component is a base metamodel. It is based on the Knowledge Discovery Metamodel (KDM) from the OMG. Actually, it is a minimal subset of KDM allowing end users to define (by extension) some KDM compliant metamodels. The framework offers facilities to manipulate models which metamodels are extensions of the base metamodel.Sobre los soportes en que se basa MODISCO:
Due to the highly diversified nature of the considered legacy, MoDisco is a collaborative project involving several organizations. Each of them will bring its own expertise in a given area. MoDisco will use as often as possible the solutions elaborated by the OMG ADM (Architecture Driven Modernization) Task Force.Puede consultarse su documentación en el mismo sitio.
(...) As a GMT project, MoDisco will make good use of other GMT projects or solutions available in the Eclipse Modeling Project (EMF, M2M, GMF, TMF, etc), and more generally of any plugin available in the Eclipse environment.
Nota: Este artículo fue adelantado parcialmente ayer. Esta es su versión "definitiva"
Nota 2: La imágen pertenece al sitio, y es reproducida en la hoja de información rápida y en el papel de presentación.
Suscribirse a:
Entradas (Atom)