De Eclipse a IntelliJ...y vuelta

El año pasado hubo mucho ruido con el congelamiento de los desarrollos de Android para Eclipse, y el paso a su IDE propia, y el gran crecimiento del respaldo a IntelliJ tanto para desarrollos con Android, como en general para Java. Contínuamente se podía observar la adopción de IntelliJ Idea por nuevos desarrolladores.
Pero ahora parece haberse presentado un cambio de política comercial de JetBrains, dueño de la herramienta, un cambio que pone en evidencia el punto débil del movimiento hacia su IDE desde Eclipse: está anunciado un nuevo modelo de relación comercial basado en la renta y no la venta de sus productos.
Basicamente, el nuevo "comprador" ya no será dueño de su instalación, salvo durante el período de renta. Es decir, esto es lo que va desde un producto construído por una amplia comunidad, capaz de evolucionar basado en el interés de sus participantes, a otro condicionado a las estrategias comerciales de sus propietarios. Como dice algún comentarista (Mike Milinkovich), aunque esta medida hoy vuelva atrás, marca una diferencia fundamental en las estrategias y horizontes de uno y otro producto.

Tendencias: IOT

El 6 de junio de 2012 se produjo el Lanzamiento Mundial de IPv6, inicio explícito del nuevo y reformulado protocolo de Internet. "IPv6" no se trató simplemente de atender la explosión social de Internet, sino que fue un paso necesario para atender a otra explosión: la perspectiva ya inmediata de extender la red de internet potencialmente a cualquier recurso susceptible de aplicarle inteligencia. Esto es, la Internet de las cosas (IOT), es decir, la posibilidad de que enormes cantidades de objetos puedan disponer algún grado de inteligencia, una dirección propia para comunicarse, y posibilidades inagotables de interrelacionarse con el mundo circundante. Sumémosle el mundo ya lanzado de la movilidad, y tendremos un universo de recursos de potencialidad sin límite. Ian Skerrett, de la Fundación Eclipse, expuso ayer mismo en pocas líneas su visión sobre el alcance de IOT. Creo que vale la pena reproducirlo, por su claridad, profundidad y síntesis:

How to categorize the Internet of Things

I was recently asked how to categorize the Internet of Things. IoT is so broad and multi-dimensional that I am not sure if there is one easy answer or set of categories. However, here is my current thinking…

1. IoT Hardware

A lot of the excitement in IoT and the maker community starts with the cheap, easily accessible hardware. Arduino, Raspberry Pi, BeagleBone are the poster kids in the space. Now there are a ton of new hardware solutions be made available, ex Parallela (16 cores for $99) , Galileo from Intel

2. IoT Standards and Protocols

There is a lot of talk about IoT protocols and which one will win. It is too early and I agree not any one protocol will win. One thing I do know is that closed proprietary solutions are not going to win. We do need to work on having a common set of standards like CoAP, MQTT, Alljoyn, SensorML, etc  Of course, we also need to make sure that we have open source implementations for these standards and protocols. That is why Eclipse IoT is so important for an Open IoT.
There will also be a lot of vertical standards that will be developed for IoT, like OneM2M, Continua, etc.

3. IoT Gateway Software

The typical IoT solution architecture will have some type of gateway solution that connect the sensors and actuators to the Internet. Eclipse Kura and Mihini are good examples of this but there are certainly others.

4. IoT Middleware

Companies like IBM, Axeda, Sierra Wireless, 2lemetry, ClearBlade, Microsoft, Eurotech, Thingworx, Litmus Automation and others are providing IoT platforms/middleware solutions. This is definitely an emerging space where all platforms are not equal. I expect to see a lot more startups and the big enterprise middleware vendors driving the innovation for IoT middleware.

 5. IoT Databases

The amount of data generated by IoT solutions has the potential to be Huge Data, not just big data. AS pointed out by Matt Asay, the exists a massive opportunity in analyzing IoT data.  Splunk seems to be the leader in this space but I expect a lot of innovation in this space.

6. IoT Solutions: IoT & Humans vs Industrial Internet

There are also a lot of  industry specific and user-case specific IoT solutions. Tim O’Reilly wrote a recent article titled ‘The Internet of Things and Humans‘ which does a very nice job summarizing the human impact of IoT. In fact a lot of the hype for IoT is around wearables and home automation.  Nest is the poster-child for IoT&H but you can’t go a week without finding another home automation solution being launched on kickstarter.
There is no doubt the human side of IoT will be important but I find the Industrial side to be a lot more compelling. SCADA systems like the London Tube system , Nespresso providing remote management of coffee machine, the work GE is doing for hospitals, aircrafts, etc. are the things  are fascinating and exciting opportunities. This is also where a lot of the profits in IoT will be made.

In the last 6 months the activity/hype around IoT has exploded. It will be fun to watch how these categories emerge and merge in the next 1-2 years. Of course an Open IoT is what is needed for all this to be successful. Eclipse IoT will be an important part of the solution.

Es hora de adelantar(se) en este escenario; ¿nuestras herramientas serán capaces de operar sobre este conjunto? ¿conocemos los recursos, infraestructura, estándares, proveedores, con los que habrá que interactuar? ¿tenemos la comprensión adecuada para transmitirla a quienes serán sus beneficiarios? Creo que sin duda, esta es la hora de los DSLs y de los modeladores y generadores de código, y comparto la expectativa de Skerrett en el papel que Eclipse pueda cumplir, por su flexibilidad y la extensión de su comunidad de usuarios y proveedores.

Android, nueva IDE?

 Oficialmente presentado en Google IO, el soporte de Android a una nueva IDE: IntelliJ IDEA, agregada a la existente sobre Eclipse. De lo que en distintas fuentes informales se puede inferir, no se trata de una IDE mas, sino de una preferente. Aunque parece ser que para los desarrolladores de Google es una excelente noticia (1, 2, en algún caso con alguna reserva,3), no estoy muy seguro que lo sea para un buen número de desarrolladores o empresas que hoy usan Android sobre Eclipse, no sólo por lo bien o mal que Android se puede usar sobre esta IDE, sino por el soporte que Eclipse ofrece en otros tipos de proyectos, que usualmente estarán conectados con Android. El valor de Eclipse está en la fuerte comunidad de desarrollo abierto, que ha montado sobre la IDE centenares de proyectos en el terreno del modelado, o de la infraestructura al  servicio de la construcción de estos proyectos. No sé si el  impacto de este cambio ha sido pesado de manera correcta.
En todo caso, si observo el tipo de críticas de los "googlers" a Eclipse, diría que están dispuestos a avanzar sobre IntelliJ con preferencia, dejando atrás a Eclipse si no es capaz de responder en sincronía a nuevos desarrollos. De sus dichos no se desprende un abandono de éste, sino un "soporte relegado".
En demérito del cambio se debería señalar que la comunidad de soporte de IntelliJ tendrá por lo general una extensión menor que la que Eclipse tendría...y que estamos hablando en este caso de una empresa comercial, de la que Android está tomando la parte de su producto que está puesta en open source. ¿Es esta una gran idea, estratégica? ¿Es comparable el alcance de la apertura y extensibilidad de uno y otro? Lo pongo en duda.
Una política que ha restado contínuamente seguidores a Microsoft es la de efectuar cambios a sus productos que dañan a su comunidad de usuarios (lo más evidente y profundo, el cambio de Win32 a WinRT). Parece ser que Google está jugando con el mismo estilo.
El anuncio del equipo de IntelliJ, en su sitio y su blog.

Buena presentación sobre MDE

Jordi Cabot publica hoy en Slideshare una muy interesante presentación sobre MDE/MDD, que, si bien hace una introducción general al tema, le dedica lo fundamental a las líneas de investigación y a los puntos problemáticos para lo que define como versión 2.0 de MDE. Dentro de las líneas de trabajo presente y futuro dos aspectos que veo particularmente interesantes son la actividad relacionada con  ingeniería reversa dirigida por modelos (mención especial de MoDisco), y el  manejo de muy grandes modelos, que parece ser un asunto de difícil solución en el marco de las premisas actuales de MDE/MDD.
La presentación es suficientemente detallada y amplia como para que pueda despertar la inquietud de aquellos que todavía dudan del valor de MDD/MDE, y más aún para quienes ya están embarcados en alguna forma de desarrollo basado en modelos. El camino es ancho y abierto...
No lo voy a reproducir: cualquiera puede ver la presentación en Slideshare.

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.

Developing App with CA Plex + CM WebClient from CM First Technologies

En mi caso, este mes, testeando Plex + Android. Quizá agregue algunas líneas sobre sus resultados.

Plex => WebClient => Ipad

Para usuarios de Plex, o interesados en mover un modelo a aplicaciones móviles: una pequeña presentación de WebClient adelanta bastante información acerca del proceso de creación de una aplicación desarrollada para Ipad con Plex. No es posible entrar en detalles sin la documentación esperada para la versión 1.8, pero da una idea de los pasos a seguir, básicamente en la misma vía que lo necesario para construír una aplicación web estándar de Webclient, pero en una Mac: Plex [en una máquina virtual]=> Eclipse [Indigo en este caso] => [PhoneGap] => Código listo. Brevemente se explica también la variante Android.

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.
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!

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.

Sugerencias que da un proyecto

Bob Fields, de Walt Disney World, comenta en The Model Driven Software Network, la  estrategia de la compañía para el desarrollo de sus aplicaciones usando Java, Eclipse, Rational, Maven. Una experiencia que recién comienza a describir, pero que ya presenta aspectos de interés si la sobrevolamos un poco, sea en general como medio de articular una línea de trabajo con MDD, o, siendo más específico, desde el punto de vista de Plex. Dice Bob:

(...) My main passion as an architect is in finding ways to improve the software development process through automation. I have championed the adoption of Apache Maven at WDPR, but much work remains before we have full adoption and integration over all phases of the lifecycle.(...) I led the effort to adopt an MDA tool several years ago. After investigating a number of alternatives (two no longer exist: OptimalJ and ArcStyler), we settled on the open source tool AndroMDA because of the maven implementation plus the mature output capabilities using velocity templates: Java, Spring, Hibernate, EJB, EJB3/JPA, Struts, JSF, WebServices, jBPM/Drools, dotNet NSpring/NHibernate/ASP.

 Es decir, articular una herramienta MDD con el mayor espectro posible de salidas, incluyendo todo en algún tipo de herramientas que permita articular y automatizar cuanto sea posible del ciclo de vida del sofware. En el caso de Plex, muchas sugerencias para extender y abrir el desarrollo, adelantándose a lo que en un momento determinado sea posible hacer con la IDE. Lo que iniciara Webclient (puente con Eclipse + Web), ampliado.

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.

Plex: A tres días de la conferencia

Esta semana, desde el 23 hasta el 25, se desarrolla la cuarta CA 2E/Plex Worldwide Developer Conference. No estaré, pero espero que el próximo año sea distinto. En el sitio de la conferencia puede consultarse el programa de sesiones para los tres días (a propósito, la grilla del programa de actividades está hecha con Plex y XML).
Quisiera destacar de su contenido, la nota inicial de Simon Williams, capaz de dar una visión en perspectiva del producto, considerando que es su constructor inicial. Y luego, la gran cantidad de material sobre la orientación de Plex a servicios Web y aplicaciones Web: Plex y WCF, desarrollo con Ajax, Plex y XML, y otras de mucho interés. Se puede observar una gran potenciación de la actividad de terceros, tanto empresas como usuarios individuales.
Trataremos de disponer aquí las presentaciones o sus enlaces públicos tan pronto estén disponibles.
La conferencia en la Wiki (estarán seguramente aquí las presentaciones).
La conferencia en Facebook.

Desarrollo de aplicaciones y Web 2.0

Rescatado de Eclipse Zone, escrito por Zviki Cohen, el catorce de abril de 2008:

The Future

As I mentioned, there are some immediate benefits from having an online IDE, especially: no installation and instant deployment. IMHO, this is just the tip of the iceberg. Here are just a few thoughts of what we might expect:

• Online IDEs open new capabilities of sharing and collaboration. Consider doing pair-programming with your colleague, which is sitting in another continent.
• This can be even more useful when it comes to outsourcing and your coworker is an occasional developer. For example, I need the services of an expert DBA. I can find one online in elance and work together on my project immediately.
• On-demand services open new possibilities: instead of buying a profiler for $500, maybe I'll just pay for the time which I'm using it.
• Mash-ups: I can use Google Page Creator to design my project's web pages and Yahoo Pipes to define a web service. All as part of the same project. Today, Eclipse is already a mash-up of OSGi services. Tomorrow, it may be a mash-up of web services or REST.
• All the online services I mentioned in this post had to developed their own IDEs. I'm sure future vendors will be more than happy to use an existing online IDE and develop plug-ins on top of it. As the number of online services provided grow, the need becomes more imminent.

I'm just guessing here, but it does open up new directions and opportunities.

Críticas a MDD desde dentro: Rigidez del código, parte II

Tratando de completar las ideas que el primer punto de Johan sugiere, quisiera volver sobre el carácter abstracto de MDD (The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't change every little detail you want).
Muchas de las objeciones atribuidas primero a MDA, pero luego extensibles a MDD (la visión ampliada y variada del diseño basado en modelos), están aquí. El primer acusado es UML, el estándar definido por OMG primero como herramienta de modelado, y luego como soporte para expresar modelos traducibles a código. ¿Es suficiente UML para expresar de manera abstracta toda la lógica de un sistema? ¿Es posible bajar en el nivel de detalle de un sistema recurriendo sólo a las herramientas propias de UML (vistas de diagramas y OCL)? Estas objeciones provienen especialmente de quienes usan o discuten MDA; sin embargo, no escapan a estas preguntas las variadas alternativas de solución ajenas a MDA (Johan describe algunas de estas variantes).
MDD, en sus distintas vertientes, probablemente esté atravesando un período parecido al que atravesara UML en la década de los 90: distintas notaciones se fueron forjando para expresar el diseño orientado a objetos, convergiendo en un esquema consensuado y no propietario, suficientemente potente como para responder a su tarea. El desarrollo de aplicaciones basado en modelos abstractos y generables, capaces de aplicarse a distintas plataformas y a distintas arquitecturas, mejorará sus herramientas y logrará mejores resultados. ¿El esquema de extensiones de Eclipse podría ser una respuesta a la apuntada "falta de flexibilidad"? ¿Alguna variante de DSLs aplicados en el espacio hoy llamado "rígido" podría aumentar la granularidad de los sistemas?
En el caso de Plex (mi herramienta de trabajo, para cualquiera que lo desconozca), este espacio está cubierto por el concepto de "diagramas de acción": llamémoslo un script abstracto, capaz de moverse en un meta nivel materializable en distintas encarnaciones, fuertemente restringido por los objetos a los que sirve (no es posible referirse a ningún objeto que no esté definido en el modelo, ni violar los tipos que manipula), que puede sin embargo ser detallado y minucioso. ¿Es una solución definitiva? No, porque globalmente podría llegar a expresar en un conjunto de diagramas algo contradictorio con el comportamiento esperado del modelo. No es sustituíble el trabajo del diseñador para expresar su modelo; un mal diseño también puede ser plasmado en un modelo escrito con UML.
En fin, digamos que el punto 1 de los ocho enumerados por Johan den Haan, pone el acento en un problema en discusión, que está en el laboratorio. Y que probablemente se refinará y quizá incluso desaparezca. Sin duda, en primer lugar, su objeción a la calidad de la interface gráfica.
En los próximos días seguiremos con otros puntos...

Críticas a MDD desde dentro: 1, rigidez del código

Desde hace pocos meses existe el foro The Model Driven Software Network (como aquí se comentó). En breve tiempo ha desarrollado un buen cruce de ideas, atrayendo a muchos de los teóricos, constructores, y poseedores de los distintos "sabores" en que se trabaja hoy en desarrollo basado en modelos. Curiosamente, en varias ocasiones se ha discutido allí en tono pesimista, poniendo acento en las dificultades que este tipo de desarrollo implica, pero dejando aparte lo que de positivo y productivo tiene. Probablemente, porque esto se da por sobreentendido, y a quienes construyen les interesa resolver los problemas en primer lugar.
En este contexto, en los últimos días dos miembros del foro han aportado algunas razones de las dificultades propias de MDD: Johan den Haan, que resume ocho razones por las que MDD es peligroso, y Peter Bell, puntualizando la importancia de la selección de un meta-metamodelo.
Particularmente las observaciones de Johan se han discutido más de una vez en TMDSN, y pueden servir de base para conversar sobre estos puntos críticos. Dado que el tiempo es escaso, conversaremos un punto por vez. Y el primero será la referencia a la "rigidez del código":

"If you're used to programming everything by hand, MDD can be quite rigid. The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't change every little detail you want. It is, for example, often the case that generated graphical user interface are inflexible and they all look like each other."

Johan menciona aquí por lo menos dos aspectos: las características del código, y las de la interfaz gráfica. Particularmente el aspecto de la rigidez del código, de una u otra forma, es uno de los más discutidos en TMDSN, y donde se proponen soluciones más abiertas. En varios casos se cuestiona la limitación del código generable, por su incapacidad de alcanzar más allá del marco estático de un sistema. Al llegar al comportamiento (behavioural model) parece entrarse en un terreno abierto e inconcluso. Distintos caminos, algunos más "rígidos" que otros.
En cuanto a la interface grafica de usuario, que básicamente podría pertenecer al modelo estático, dificultades para definirla con el grado de detalle que se desee deberían considerarse limitaciones de la herramienta particular con la que se trabaje.
Pero volviendo a la posible "dureza" del código, esto tiene dos aspectos: la capacidad del modelo de expresar un problema, tan flexible y detallado como se requiera, y la calidad del código generado al transformar el modelo en código ejecutable. Es mi parecer que la herramienta que se use debe ser capaz de modelar el problema, y que si no lo logra, es incompleta. Estoy seguro de que casi todas las existentes son capaces de expresar una solución tan completa y articulada como se requiera. Y que esta capacidad puede refinarse progresivamente para ser todo lo dúctil que haga falta. Por otra parte, sin duda será rígido el código final ejecutable que se genere: Dado que el código proviene de las transformaciones preestablecidas entre el modelo y el código fuente resultante, éste siempre será escrito de la misma forma para los mismos elementos de modelo que "traduzca". Si bien eso es cierto, también es cierto que se trata de código probado, y que siempre será igual de confiable. Por supuesto, el todo generado no necesariamente será optimizado o seguro, pero esto es solucionable en un nivel más general: siempre es posible (y necesario) optimizar las transformaciones. Usualmente estas transformaciones son modificables, y, aún más, en muchos casos se trata de contrucciones "ad hoc". De paso, a mi entender, esta es la única vía de refactorizar en el desarrollo basado en modelos.
Donde se puede hablar de problemas con el código, es en el modelo dinámico (behavioural model). Muchas herramientas generan sin dificultad el modelo de clases, pero allí se detienen, requiriendo completar el comportamiento mediante extensiones construídas con programación estándar. Eclipse es preferido por muchos por su modelo basado en extensiones, y la posibilidad de integrar estas (construídas en código java en general) con el modelo al que soporte. Sin embargo este no es estrictamente el punto cuestionado por Johan. Lo tomaremos en otro momento...
Queda más por conversar. Recapitularemos en la semana.

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):

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.
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.

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.
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á.

Plex: Webclient i+

ADC Austin anuncia este mes su release 1.4.6 de su Webclient, la alternativa que desarrollara en conjunto con Websydian, basado en modelos Plex. Para quien no conozca el producto, esta es la presentación resumida en su wiki:

WebClient is an extension to the CA Plex development environment. It allows CA Plex-developed Java GUI applications to be deployed as web applications with minimal modifications.

In order to use WebClient to deploy an application, you must:

• Have an application that is configured for and operational as a Plex Java client/server application
• Have a Java EE-compliant web application server
• Build and deploy the application using the Eclipse development environment

WebClient consists of two principal components:

• A template generator which runs during the generate and build process. For each Plex GUI panel, a file is generated which contains the HTML and Javascript code needed to display the panel as a web page. The generated templates can be customized to alter the look and feel, implement new controls, and provide additional functionality to the panels.
• A servlet that is loaded into the Java EE application server at runtime. The servlet loads the Plex-generated Java application's class files and allows them to communication to and from the web user using the generated templates.
  

Crecientemente, distintos socios de CA, embarcados en extender Plex, exploran las nuevas tendencias en Model Driven Design para lograr mayor alcance, tanto para crear puentes con otras aplicaciones y paradigmas de modelo, como para abordar nuevas plataformas y arquitecturas. Este es uno de los ejemplos en curso. Cobra importancia Eclipse en este y otros proyectos.
Volveremos sobre el tema.

La posible adquisición de SUN

James Gossiling opina sobre la eventual compra de Sun por IBM; recogido por Jason Stamper, en Computer Business Review:

Gosling insisted the rumoured acquisition is, “Obviously just speculation at this point.”

But asked about the different cultures within IBM and Sun, and in particular their developer staff, Gosling said: “There would definitely be a culture clash. We’re definitely weirder than they are.”

“We grew up from a bunch of hippies, almost with flowers in our hair,” said Gosling.

Although the firm was founded in 1982, its proposition, which involved the peddling of open systems in general and Unix in particular -- and more recently its transition into a major contributor to the open source software movement – has given it a certain hippy, perhaps even radical culture. Especially when compared to the more proprietary computing platforms that preceded it, IBM included.

But Gosling suggested that it would still be possible for Sun and IBM staff to settle their differences: “We’re a much more grown-up company now [than when Sun was founded] with a very different group of people. We’ve become a full-on enterprise software company,” he told CBR.

Asked whether it would be interesting to try and in some way combine some of Sun’s NetBeans open source development framework technology with IBM’s rival Eclipse project, Gosling said: “It would certainly be possible. We have been partners on the Java journey for quite a few years. In many ways there would not be a huge impact on Java development.”

But in a statement that perhaps has ramifications for IBM’s rumoured acquisition of Sun, Gosling – the inventor of Java – said that the Java community is now, “Such a large community of people that nobody could control it. If anybody tried, it would ruin it all.”

Desde hace tiempo, ambas empresas tienen más puntos en común que diferencias en su orientación a Open Source. Una eventual absorción probablemente favorecería la actividad en Eclipse. Y quizá por el lado de IBM ampliaría su soporte a Java, creciente sobre sus equipos de rango medio (ISeries). Sin embargo, una compra tiende más a ser la absorción y eliminación de un competidor en el mercado. Dana Gardner, en ZD Net, duda de su viabilidad y realidad:

By buying Sun IBM gains little other than some intellectual property and mySQL. IBM could have bought mySQL or open sourced DB2 or a subset of DB2 any time, if it wanted to go that route. IBM has basically already played its open source hand, which it did masterfully at just the right time. Sun, on the other hand, played (or forced) its open source hand poorly, and at the wrong time. What’s the value to Sun for having “gone open source”? Zip. Owning Java is not a business model, or not enough of one to help Sun meaningfully.

So, does IBM need chip architectures from Sun? Nope, has their own. Access to markets from Sun’s long-underperforming sales force? Nope. Unix? IBM has one. Linux? IBM was there first. Engineering skills? Nope. Storage technology? Nope. Head-start on cloud implementations? Nope. Java license access or synergy? Nope, too late. Sun’s deep and wide professional services presence worldwide? Nope. Ha!

Let’s see … hardware, software, technology, sales, cloud, labor, market reach … none makes sense for IBM to buy Sun — at any price. IBM does just fine by continuing to watch the sun set on Sun. Same for Oracle, SAP, Microsoft, HP.

With due respect to Larry Dignan on ZDNet, none of his reasons add up in dollars and cents. No way. Sun has fallen too far over the years for these rationales to stand up. UPDATE: Tony Baer likes Fujitsu as Sun savior.

Only in playing some offense via data center product consolidation against HP and Dell would buying Sun help IBM. And the math doesn’t add up there. The cost of getting Sun is more than the benefits of taking money from enterprise accounts from others. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

Eric Newcomer pone el acento en la competencia por el liderazgo de la comunidad Java, y sí considera que existe interés de parte de IBM en la compra, particularmente si futuros desarrollos de Sun siguieran un camino distinto del que hoy otras empresas tienen embarcado:

The hot topic of debate today is the breaking news story that IBM is in talks to acquire Sun. Dana Gardner doubts this, and a bunch of myFB and Twitter friends ask the obvious questions in their status updates: Why the heck would IBM want to do this?

I haven’t seen anyone yet bring up the Java question. As co-chair of the OSGi EEG and formerly 9-year employee of a Java vendor, I have seen the battles between Sun and IBM over the control of the Java langauge up close. It has never been a pretty picture.

Recently I was asked about Jonathan Schwartz’s blog entries about Sun’s future direction and corporate strategy. The content of these entries has been subject to the usual praise and criticism, but I haven’t seen anyone talk about what’s so obviously and painfully missing - at least for someone active in the Java community and trying to push the ball forward (e.g. enterprise OSGi). Where is the talk about leading the Java community? Where is the talk about collaboration with IBM, Oracle, Progress, Tibco, and others? Where is the description of how helpful Sun is toward Apache’s Java projects (especially Harmony)?

IBM has ported many products onto the OSGi framework during the past several years, including flagship products such as WebSphere Application Server and Lotus Notes. Never mind the fragmentation in the Java community caused by the disagreement over SCA. What about Sun’s recent announcement that they were going to reinvent Java modularity in the Open JDK project, all on their own, without input, without regard to what happens to OSGi? What kind of potential change cost does that represent to IBM and all the other Java vendors who have ported products onto OSGi?

The potential acquisition of Sun has been debated so far mostly in terms of the business value Sun has - that is, in the context of where it is still making money, as if that were the main or only reason for an acquisition. But I say again, what about the unrealized potential for collaborative leadership in the Java community? Sun obviously isn’t paying attention to this, but IBM might be.

Para más información, la eventual compra, analizada por The Wall Street Journal.

The Model Driven Software Network se pone en marcha

Adelantado hace unos días, esta red de discusión sobre desarrollo basado en modelos comienza a trabajar: en alrededor de una semana, ha sumado setenta y cinco miembros, y ha iniciado dos o tres líneas de discusión de mucho interés. Y los miembros que se incorporan pueden aportar mucho, ya que representan una suma importante de conocimiento y práctica en este terreno.
Contradictoriamente, la línea de discusión de mayor interés en la primera semana, se pregunta si MDD ha muerto. Más adelante, se expondrán aquí algunas ideas al respecto.

Plex en Eclipse

Christopher Smith, en su tiempo libre, está desarrollando en SourceForge un plugin para soportar el desarrollo con Plex. Para quien le interese la combinación de Eclipse/Plex.
De su comunicación en el foro de Plex:

The complete Eclipse project for Plex Services for Eclipse is now hosted at SourceForge.

The project is located at http://sourceforge.net/projects/plexservices/

The subversion repository is located at https://plexservices.svn.sourceforge.net/svnroot/plexservices

This project is licenced with the Apache 2.0 open source licence so please use it and contribute.

If you want to just install the plugin, an Eclipse update site is available at http://adcaustin.com/eclipse/

There is a half completed setup page on the Plex WIKI.

Please remember, I'm doing this in my spare time. If it needs a feature or a fix, I will try and help as best as my schedule allows.

If you have a question on how you can extend it and want to share, I will be MORE than happy to answer.

The plugin currently requires at least Eclipse 3.3 and I'm targeting my future development for 3.4.

Como Christopher dice, en la Wiki de Plex se puede encontrar más información:

How does Eclipse relate to Plex?

Plex can generate Java source code for very functional and usable applications. Building, Debugging, Deploying and Managing the generated source is not an easy or straight forward task. Eclipse can handle these tasks for you.

Plex 5.X ships with Microsoft's NMAKE as it's Java Builder (6.0 uses ANT). Building a large Applications can take a very long time. Eclipse can build your application in a fraction of the time. Diagnosing build errors with the compile listings from NMAKE is clumsy, if not impossible. Finding and discovering how to correct build errors in Eclipse is quite simple.

Debugging Java without an IDE can be very difficult. Debugging is inherent part of the Eclipse Platform.

Deploying a Plex Java application is a cumbersome manual process. Eclipse, along with the integrated ANT support, can automate the whole process. You can even create J2EE projects in Eclipse to automate the packaging and deployment of Plex EJB Proxy applications to J2EE servers.

Managing a single developer environment of Plex generated source code and other required artifacts is difficult to impossible, never mind trying to do so in a multi-developer environment. Eclipse provides a "workspace" for each developer and source repository support for source control products like CVS and Subversion.