Un afilado comentario sobre el estado del uso de modelos

Scott Finnie publica a finales de Septiembre un acertado comentario (a mi juicio por lo menos) crítico sobre el estado y evolución del uso de modelado en la vida real, en sus distintas vertientes actuales. Finnie encuentra que algunas de las tendencias en modelado han evolucionado mal, y prácticamente no encuentra alguna via conceptual o herramienta aplicada que sea totalmente satisfactoria.
Finnie comienza dedicando un párrafo breve a los métodos más formales, que considera en general inaplicables por sus exigencias:

Formal methods can definitely contribute to the “better software” imperative. Any impact on “faster” is a second order effect however: the models have to be translated into working software by hand. And the learning curve can be steep, requiring a solid foundation in the theory and notation of one or more mathematical disciplines (predicate logic, sets, graphs).

En segundo lugar, Finnie se ocupa de los lenguajes específicos de dominio (DSLs) sobre los que señala sus límites de adopción en la dificultad que representa sumir la creación de lenguajes adecuados a una diversidad de problemas por parte de equipos de empresa. Sólo los ve aceptables en nichos de empresas cuyo producto es el software, en general:

Domain-specific approaches can directly address both “better” and “faster”. But they are not without hurdles, both technical and organisational. On the technical front it’s the challenges of language design. Textual approaches (e.g. Spoofax, Xtext, MPS, Rascal) require the designer to understand compiler construction: parsing, linking, semantic analysis, type systems and so on. Graphical approaches such as MetaEdit+ perhaps simplify that. But there’s still the question of designing a language.
The organisational barriers are at least as significant – and independent of the textual/graphical debate. Getting traction for a DSL depends heavily on the organisation’s approach to software. It’s possible in companies building software products, especially those offering related product families. The cost of investing in language design and tooling is justified through repeatability and hence efficiency. But not all software falls into the “product family” bucket. Even when it does, some organisations – and many developers – are nervous about building a proprietary language. Maintainability, recruitment and CV curation can be powerful adversarial forces.

Finalmente, se enfoca en los lenguajes de modelado de propósito general, de los que espera más, pero encuentra grandes dificultades. La principal objeción a este tipo de modelado, enfocándose fundamentalmente en UML, es la incapacidad de casi todas las variantes desarrolladas de pasar de un esquema más o menos definido, a código ejecutable, o como suele decirse, a modelos ejecutables:

The vast majority of UML models are mere sketches. Sketches aren’t working software.
Sketches need lots of human endeavour to translate them into working software. Which isn’t to say they’re bad: a quick diagram on the whiteboard can be invaluable. But it’s a long way from working software. At the height of its hype curve, the UML wasn’t capable of describing precise, executable models(²). Without those, it’s impossible to automate software generation. Without automation, we don’t get better software quicker.
This is the fundamental mistake with MDA:

1. An incomplete language intended for sketches is not a viable basis for precise, executable models.
2. Without precise models,
   1. no formal checking can take place. So the impact on “better” is marginal;
   2. no process automation can take place. So the impact on “faster” is at best nil.

Summing up: MDA didn’t deliver better software quicker. It had the hype and the backing of large organisations. It didn’t stick because, brutally, it didn’t work.
So – in the context of general purpose modelling – let’s be clear about this: as long as a manually intensive process sits between a model and working software, the model is no more valuable than a sketch.

Finnie sostiene que hoy están dadas las condiciones para reparar estas faltas. Enumera una lista de asuntos por ajustar y resolver, con final abierto:

• whilst there are a plethora of tools for building models, few of them support executable models. Of that few, far fewer still are actually rewarding to use.
• we’re missing the pre-existing models that serve as exemplars. Models that are demonstrably translated into real, working software. Models that can be adapted or reused to meet different requirements.
• we’re missing the translators that turn those models into working software. Automatically, quickly and repeatably. We have the tools to write those translators: we don’t have the translators themselves. At least not robust, industrial quality translators that produce robust, industrial quality software. That can be used by real users or sold to real customers. Results that looks as good as, and function as well as, ‘hand written’ alternatives. Crucially, those translators need to be open for adaptation.
• we’re missing the cohesive environments that make it easy. Environments that don’t need weird hacks or obtuse incantations to make them work. Tools that “just work”. Tools that combine the constituent parts for modelling and translation into a consistent, seamless, industrial-quality experience.
• we’re missing eco-systems that pull these things together to forge communities. Communities that generate interest because they’re doing cool stuff.

Ante esta discusión, que creo que sigue siendo de interés fundamental, desde nuestra comunidad de usuarios de Plex...¿cuántas oportunidades se han perdido  en este camino para lograr una mayor abstracción y alcance?
Nota: si lee el artículo de Finnie, no deje de leer también los comentarios posteriores.

Septima conferencia mundial de Plex

Este pasado mes de junio se celebró en Austin la séptima conferencia mundial de Plex, con gran participación de CM First, haciendo casi de anfitrión, en la ciudad de su sede americana. Y como corolario de este hecho, en gran medida las sesiones y discusiones de mayor interés provinieron de sus presentaciones, que abarcaron el desarrollo para web y movilidad, y servicios web. Particularmente la discusión del tema de servicios web, en especial de REST, fue uno que continúa generando todavía un poblado hilo de discusiones en la comunidad de usuarios (ver particularmente las discusiones 1 , 2 y 3). La conferencia quedó en hiato, en paréntesis, por el posterior cambio de funciones dentro de CA del responsable mundial del producto, Simon Cockayne, pocos días después del cierre de sesiones: está por verse el compromiso actual de su nuevo responsable, Daniel Short,  con las conclusiones y recomendaciones de la Conferencia.
De las diversas sesiones ofrecidas, quisiera destacar una en especial, acerca del uso de Webclient por parte del equipo de desarrollo de United Heritage Insurance, porque la explicación de trabajo de adecuación de plantillas de Webclient es una buena herramienta para cualquiera que use o desee usar Webclient. Si usa o piensa usar Webclient, no deje de descargar una copia de la presentación.
El conjunto de sesiones puede consultarse en el sitio de la conferencia.

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:

STOP Coding - Start Architecting
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.

La 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"

Java en el System i

La JVM de IBM vs el JDK clásico. Cap 13, pag 591

Continuando el comentario (y recomendación de su  lectura) del Red Book sobre modernización del System i, dos palabras sobre Java en  el i.

Siempre se discute la lentitud de Java y su manejo de espacio de memoria, pero deberíamos decir que esto depende mucho  de la implementación y del aprovechamiento de las herramientas disponibles. Particularmente, IBM ha hecho un cambio radical en la JVM: el reemplazo por la implementacion de IBM,  Por experiencia, hemos pasado por casos que comenzaron con fallos y caídas, y fueron ajustados y optimizados hasta pasar a un funcionamiento absolutamente normal. En el capítulo 13 del red book, se comenta sobre la lentitud de Java (13.3.2 Myths surrounding Java: Java is slow)

Is Java really slow? It depends on what you compare it to. (...) you must choose the correct tool for the job. If what you need is high performance, you must select a lower-level language, such as C/C++ or RPG, but if you are dealing with huge and complex applications, it might be better to use a language with more flexibility, such as Java.
The reputation for slowness that Java usually carries is related to the JVM and not the language itself. The Java language is dependent on multithreads and large amounts of memory. Many people who are accustomed to running other languages starve their Java applications, which causes terrible performance. On the IBM side, the Classic JVM was not designed for IBM POWER architectures. It was ported from the original Oracle version, which resulted in performance issues. However, IBM Technology for Java is designed for the platform and it has been highly optimized by IBM to leverage the Power architecture. With this new version of Java, you can take advantage of the multithreading nature of Java, which was not possible before. Lastly, processor technology has improved greatly over the past few years. Processors are geared toward multithreading, which is a significant boost to Java based applications. 

Disponible desde 1998, ha pasado mucho desde su introducción en el System i, progresando hasta ser hoy una alternativa confiable. IBM comenzó ofreciendo soporte a la JVM clásica de Java, hasta que decidió atacar los problemas de adecuación a la plataforma, desarrollando su propia versión, tanto de un conjunto de clases y servicios que explotan los recursos nativos del equipo (IBM Toolbox for Java), como de una propia JVM, que ajusta la versión clásica desarrollada hoy por Oracle:

Java on IBM i can take advantage of the 64-bit architecture of the systems to provide a scalable solution from single processor machines all the way up to multiprocessor machines. The Classic JVM was unique in its implementation of asynchronous garbage collection, which allowed the JVM to continue processing application requests during the garbage collection cycle.
Nevertheless, this uniqueness of the Classic JVM became a disadvantage. For many developers and vendors, it required much work to port their applications to the IBM i, which disabled the portability features of the Java platform. This also resulted in more expenses to IBM and slower releases of the new Java versions and updates. In addition, the Classic JVM was based on porting code that was not tuned to the features built within the IBM PowerPC architecture. Starting in V5R4, IBM i started to move away from the Classic version of Java and support for Classic is now stabilized. Today, Java is delivered on IBM i only through the IBM Technology for Java version.  (...) Initially the IBM Technology for JVM was implemented only on 32-bit architecture, but since IBM i 6.1, the 64-bit version is available for use. This gives more flexibility for developers, allowing them to fit the JVM according to their needs.

Este es un aspecto importante a tener en cuenta: las nuevas ediciones del sistema operativo implementan sólo la versión de Java de IBM. Así, Java 7 es implementada solamente en la versión de IBM. Sin embargo, esto no debería alterar la ejecución de código, sino explotar la posibilidad de usar de manera nativa servicios y posibilidades del sistema operativo y de la base de datos. El "IBM Toolbox for Java" y su equivalente open source JTOpen ofrecen un excelente medio de interactuar con los recursos del sistema.

En nuestro caso, el desarrollo de aplicaciones web con Webclient, que utiliza java como capa intermedia, nos ha dado oportunidad de comprobar la posibilidad de usar java sobre el System i. Básicamente, nuestras aplicaciones se ejecutan sin diferencias (salvo extensiones que concientemente explotan facilidades del sistema) sobre servidores Websphere en System i, iSeries o como se le llame, y sobre servidores Tomcat o Jetty (en este caso sólo para pruebas). Y quisiera decir que, además, las herramientas de análisis de problemas y performance que Websphere ofrece, son superiores al momento de tener que estudiar problemas. Probablemente, la posibilidad de usar Java nativamente es una de las mejores garantías de modernización y explotación del equipo, convirtiéndose en un puente entre el mundo móvil, web y de recursos infinitos que propone IOT, y la potencia de procesamiento y de manejo de datos del i.

7.ª conferencia mundial de Plex/2E:

Se publicó ayer la agenda de la séptima conferencia mundial de Plex, programada para el primero de junio, hasta el cinco. Como es usual, habrá un buen número de sesiones a cargo de usuarios y socios de negocios, algunas de ellas en castellano. De entre ellas, quisiera destacar algunas relacionadas con web, movilidad y servicios web:

Developing Mobile and Web UX Workshop, a cargo de Abram Darnutzer y Andrew Legget, de CM First, acerca de la extensibilidad de Plex a aplicaciones móviles:

Do you need to extend your legacy Plex app to mobile, but aren’t sure how to get there? Join us for some hands on training for developing multi-channel responsive HTML5 apps that can be deployed to desktop browsers and mobile devices. We will have exercises and detailed information on everything you need to be successful: everything from geolocation, camera imaging, social auth, native app store wrapping techniques, offline storage, device specific capabilities and more. You will leave with a working Order Processing and Delivery app that can be used off-line.

REST API’s in a CA Plex Context, presentada por Lorenz Alder, de CM First, introduciendo probablemente uno de los temas de mayor interés desde el punto de vista de arquitecturas:

This presentation first discusses general aspects of web API design and give some guidance and best practices. We will then focus on RESTful API’s and answer questions like: What is RESTful? What is HATEOAS? What is RPC? and try to find a pragmatic approach to RESTful or REST based API’s. In the last section we will talk about the status quo of the CA Plex generators and how they fit into the REST paradigm and show some ways to move from a client server centric perspective to a web perspective.

HTML5, The Future for App Development, Keynote del equipo de Sencha:

This session will provide a side-by-side comparison of developing a multi-channel, multi-platform application in HTML5 relative to a siloed or native development approach. The presenter will explore not only development issues, but application deployment, testing, and on-going maintenance issues as well.

En las sesiones de 2E se discutirá, en 2E Training Workshop (What’s new in r8.7?), un tema que espero ver también disponible en Plex tan pronto como sea posible: la extensión del manejo de las características del SQL en DB2, algo que parece incluír en el release incremental 7.2, si leo bien el anuncio ("the new features in CA Plex r7.2 Incremental Release 1 that help enable these goals"):

Do you want to move from a traditional DDS database to an SQL-type database, and still continue using your existing application? Do you want to use meaningful names on your SQL/DDL databases instead of implementation names? Do you want to be able to generate SQL/DDL type objects into any library of your choice? These are now possible with the latest release of CA 2E – r8.7. Our CA Staff will walk you through the important features of CA 2E 8.7 and also have a hands-on session to try out these new features.

De destacar también , varias sesiones acerca de la variante .NET,  facilidades de productividades en la IDE de Plex, o , especialmente, algunas dedicadas a vincular el desarrollo de aplicaciones Plex o 2E con ofertas de infraestructura de CA, con algunos aspectos de mucho interés (estoy tratando de seguir la vinculación de 2E/Plex con  CA API Gateway -sesión CA 2E – A player in the AppDev Strategy).
Sorprendentemente, no veo ninguna sesión organizada por los desarrolladores de Websydian. Es particularmente curioso porque han participado en la preparación de la conferencia, hasta donde conozco.

En fin, un conjunto de sesiones que apuntan a problemas bien actuales. No está mal.

Plex en el System i

Y a propósito de modernización en el System i (o 400, o iSeries, o...), ¿cómo está Plex? En un breve inventario, podemos decir que el RPG ILE  está soportado, así como el SQL ILE RPG. Pero construcciones complejas no lo están, tanto en cuanto a las posibilidades extendidas del ILE (Integrated Language Environment) como en cuanto a la generación de servicios disponibles en alguna plataforma (servicios web, tal como hoy es posible usar WCF en .NET, especialmente), o deseables por su propia importancia, como las extensiones para acceso web, móvil, el soporte de cloud computing, la ampliación del uso del SQL, la integración con Linux, Mac, Windows... ¿qué hay del soporte de PHP, Ruby, o la inclusión de Node.js en el sistema?
Algunas de estas características o facilidades están ya disponibles a través de terceros: CM First permite mover desde el System i a aplicaciones web y móviles tanto modelos de 2E como de Plex, así como se lo puede hacer con Websydian. Servicios web fueron abordados ya hace tiempo por Websydian. En cloud computing  CM First ha iniciado desarrollos con EC2 DE Amazon. Existen múltiples patrones desarrollados por miembros de la comunidad de Plex, tanto para el uso de SQLRPG, como para el uso de servicios web, entre otros. Desarrollos corporativos a veces compartidos y a veces apenas conocidos por la comunidad de usuarios.
Pero lo más importante es que existen varias solicitudes en curso de actualización del soporte de ILE, que aparecen como candidatos a ser incluídos inicialmente en la versión 7.2, aunque más probablemente en la 8. Entre ellas, una ampliación de la generación de código para SQLRPG, el manejo de datos varchar, el paso de la creación de DDSs a DDL. ¿REST? En algún momento Simon Cockaine preguntó a la comunidad sobre su uso, lo que puede incluírlo o no.
Visto en conjunto, una respuesta irregular pero no muy lejana de las posibilidades de la plataforma. El uso del API del OS/400 permite un flexible acceso a los recursos, aunque se extraña una respuesta más avanzada de quienes debieran conducir el producto.

Iniciadas las "CA Plex (& CA 2E) Office Hours Series"

El 20 de febrero CA anunció el inicio de las "Office Hours" para Plex y 2E: un punto de encuentro para discutir en forma abierta e informal entre clientes y personal de CA de soporte de los productos. El primer encuentro se produjo el 18 de febrero, para usuarios de 2E. Y ayer, 18 de marzo, se celebró el primer encuentro de Plex, con una buena participación y presentación de asuntos de interés.
Esta primera discusión ha resultado actual, relacionada con el contacto con nuevas plataformas y arquitecturas, y seguramente este mismo priimer hilo continuará abierto por un tiempo más. Fue, a mi juicio, especialmente interesante la pregunta lanzada por Simon Cockaine acerca del uso de microservicios y/o REST, no respondida en el momento pero merecedora de dejar abierta. Otros asuntos: el uso de Plex en un entorno ASP .NET, y la eventual actualización/modernización/ampliación de las librerías de patrones. Si usted es usuario, y alguno de los temas discutidos le preocupan, participe en el hilo abierto, o propóngase intervenir en la próxima cita, el 20 de mayo. Una activa intervención en estas Office Hours de más y más usuarios dará mayores garantías de que Plex evolucione en una dirección que sea favorable para todos.

Plex: algunas actividades en marzo

Este primer trimestre de 2015 trae algunas novedades relacionadas con Plex: temprano, en enero, George Jeffcock anunció su decisión de soportar el conjunto de patrones elaborados de Pattern Factory, publicado ahora en su sitio de Stella Tools . Pattern Factory fue durante años un conjunto muy interesante de patrones de uso y código abierto, desarrollados por Peter Fabel. La republicación de los patrones en el dominio de Stella Tools permite acceder a ellos nuevamente.
También de mano de George viene el anuncio del establecimiento de un puente entre Plex y la herramienta de administración de cambios y distribución de paquetes TDS/OMS de Remain Software, de Holanda. Es interesante su comentario:

I propose a CA Plex developer will be very familiar with the CA Plex Object Browser and would like to use it to orchestrate which objects are to be managed by a 3rd party tool. Ideally the CA Plex IDE would support traditional OLE drag and drop to 3rd party but with this unsupported, creating a Model API application in between the CA Plex IDE and the 3rd party is the next best solution.

In the case of CM First's Matchpoint Product it offers in my opinion the closest integration to CA Plex possible aided by the fact it is written in CA Plex and so no need for the intermediate Model API dialog.

With Softlanding's Turnover (originally written in CA Plex) and Remain's TD/OMS both being Eclipse based, wouldn't it be nice (well we can dream) to make the CA Plex IDE into Eclipse.

En febrero, CM First anunció el soporte movil de su herramienta de administración de cambios, Match Point, comentada antes por Jeffcock.
También este mes, mañana mismo, se desarrolla una conferencia sobre Plex en Milán, promovida por AXSOS, Mondo Software y Websydian.
Aceptable comienzo de año...
 

Séptima Conferencia Mundial de CA 2E/Plex

Del 1 al 4 de junio de este año se desarrollará la séptima conferencia mundial de Plex y 2E. Planeada inicialmente para una fecha más temprana, finalmente está confirmada para junio. Esta vez las sesiones se realizan en Austin, Texas, con el soporte de CM First. En cierto modo, su localización en Texas favorece la participación de colegas de Latinoamérica. Se ha conversado sobre la posibilidad de que varias sesiones sean en castellano. Actualmente, tanto desde la conferencia como desde la comunidad de Plex/2E se está promoviendo la participación de usuarios con sus propios proyectos en las sesiones. No existe detalle de las sesiones todavía, pero las versiones lanzadas (CA 2E V. 8.7, CA PLEX V7.2) están anticipadas como parte del contenido. Existen muchas propuestas, y esperamos su mejor definición en las próximas semanas.

Fin del soporte de Plex 7.0

Al anunciado retiro del soporte de Plex 6.1, efectivo ya este año (junio de 2015) , se une ahora el aviso de "End of Service" para la versión 7.0, comenzando en enero de 2016. Con el anuncio ya comentado del lanzamiento de Plex 7.2, comenzamos a ver una actualización tecnológica que era muy necesaria. Insuficiente todavía, pero más próxima al nivel de los productos con los que Plex opera: Visual Studio actualizado parcialmente (para WCF connectors, pero no para clientes C++, algo más que engorroso), java actualizado a java 7. Todavía queda camino por recorrer, pero se viene cumpliendo la política de cambios en ciclos muy cortos.
Haga sus planes de evolución.

Lanzamiento del nuevo release Plex 7.2

Ayer CA comunicó la disponibilidad del release 7.2 de Plex. Mucho se ha conversado sobre qué incluiría, pero nada es adelantado en el anuncio. Lo que sí es adelantado es algo ya conocido, pero igualmente muy prometedor: la adopción de una política de releases incrementales rápidos, y con participación directa de todos aquellos clientes que deseen sumarse al plan:

The CA Incremental Release Program is a customer-interactive delivery model where new product features are developed and released using the Agile development methodology. CA’s development teams work closely with customers to create product features for rapid implementation. Rather than spending years building a software release full of features, we work with customers and release features incrementally, as they are completed.

El lanzamiento de la versión 7.2 es una confirmación de esta política, acortando todavía más los tiempos de entrega ya vistos entre la versión 7.0 y 7.1.
De la documentación inicial se desprende que el grueso de los cambios se concentran en la variante .NET y en WCF Service Connectors, el agregado de soporte para Oracle 12, y la esperada actualización del soporte de Visual Studio...2010. Se afirma que es posible el soporte de versiones superiores, pero no está testeado (VS 2013). En cuanto a Java, continúa soportado hasta la versión 7 (ya existente en 7.1) y en cuanto a OS400, el soporte alcanza a IBM i 7.1.
Evidentemente, hace falta la participación de la base de clientes, si queremos ver otras nuevas características disponibles.
Plex 7.2 en la wiki oficial (CA).
Lista de fixes en la wiki oficial de Plex.
Matriz de compatibilidad de Plex 7.2 (requiere usuario).

Plex en la transición de Visual Studio...(y otras transiciones)

Mientras Plex 7.2 continúa en beta, y nuevos cambios de arquitectura aparecen en el horizonte, me interesaría retomar una conversación iniciada en mayo: qué hacer con la variante c++ (WinC) de Plex. Como se mencionara entonces, existe una iniciativa expuesta por Simon Cockayne, product manager,  por actualizar el soporte de Visual Studio de 2005 (qué horror!) a Visual Studio 2012 "o el más reciente que exista". Algo más que necesario...Pero a partir de este punto, existen diferentes líneas de avance. Dos o tres ideas sobre esto:

Algunas respuestas sugieren pasar entonces directamente a una variante .NET, esto sería, dado que la línea principal de trabajo en CA Plex parece apoyarse en .NET, evolucionemos a ella. Pero esto presenta tres escollos, a primera vista: Uno, económico, ya que no se trata simplemente de reconfigurar el modelo para adoptar una nueva variante (cambiar el valor de un combo box en la ventana de configuración), sino de pagar nuevas licencias, una por cada asiento que vaya a trabajar generando en la nueva configuración. Aunque existan ofertas o paquetes de negociación, es un costo que hay que pesar.
Un segundo escollo de importancia es la migración: no se trata tan solo de migrar paneles, sino de inventariar el conjunto de APIs de bajo nivel que se hayan estado utilizando basadas en c++/win32, y probablemente reescribirlas. Se trata de tener en cuenta la diferencia de modelo de arquitectura (managed/unmanaged code; framework de .NET). Todos los interesados, (y aquí se debería incluír también al soporte de CA) deben pesar el impacto de migrar no solo el código evidente, sino también cualquier dependencia de ActiveX, OLE, COM y VBScript. Todo ha sido afectado por el modelo .NET.
Y el tercer escollo a tener en cuenta es .NET en sí mismo: este parece ser un buen momento de la arquitectura, considerando los planes para abrirla a la comunidad en general. Pero atendiendo a los adelantos informados, no está claro que la apertura sea suficiente ni exenta de nuevas contradicciones. Este es un tema que requiere ser tratado por separado. Pero además, tampoco está claro qué papel tendrá finalmente .NET en los planes futuros de Microsoft, considerando su evolución a la nube, y los cambios de arquitectura desarrollados a partir de Windows RT.

Entretanto, no sólo evoluciona la arquitectura de Windows en general, sino también Visual Studio y el propio c++, tanto el estándar en sí mismo como la interpretación de Microsoft: hoy c++ 11, con planes para c++ 17. ¿Cómo de integrados están los planes en curso? Considerando la experiencia pasada, me pregunto, con pocas esperanzas de que se pueda tomar un curso preventivo, si no hubiera sido estratégicamente preferible, largo tiempo atrás, mantener un núcleo del generador mas apoyado en el estándar y algo distanciado de los planes de desarrollo de Microsoft. La variante de Plex es WinC, e implica un compromiso con Windows ya en su nombre: así WinC se ha desarrollado apoyado en las MFC, en ActiveX y VBScripts, y en mucha menor medida, en OLE y COM. Ahora cualquier plan de evolución o migración debe partir de este hecho. Un escenario algo más mediado hubiera permitido ver el código c++ con un mayor grado de portabilidad. En fin, la encrucijada por .NET o no, es una propia de Microsoft, en un universo cada vez más abierto, y cuando el propio Visual Studio se ve obligado a contemplar extensiones para otros sistemas operativos. ¿Podría ser conveniente persistir en Visual Studio, y abordar a partir de allí la entrada a otros medios? en fin, la apertura de .NET se propone entrar en Linux y OS X . Apuesta dudosa...Pero esto requiere una nota aparte.

Una wiki de Plex oficial

Desde hace ya ocho años aproximadamente, la comunidad de usuarios de Plex sostiene y ha hecho crecer una wiki que se proponía difundir el producto, y reforzarlo con artículos enfocados en aspectos difíciles de entender, o la descripción de variantes novedosas de uso del producto. Un gran esfuerzo sostenido especialmente por la gente de Desynit, pero acompañado por muchos otros, que dejaron un producto robusto, aunque difícil de navegar. No es la única que existe (también puede mencionarse más enfocada a la que AllAbout sostiene), pero es la más completa y profunda en sus contenidos.
Ahora, hace un par de días, CA, aparentemente en el marco de una política de "wikificar" todos sus productos, acaba de lanzar su versión oficial de una wiki para Plex. Contrariamente a la primera existente, esta no parece ser modificable por la comunidad de usuarios, sino sólo por la propia empresa. Por ahora, la invitación es a leerla y sugerir correcciones o ideas. Valga, no sería el único caso y tiene sentido defender la integridad de su contenido. La "antigua" wiki ha tenido que ir cerrando la participación de colaboradores externos después de ser blanco de centenares o miles de ataques de spammers, hasta el punto en que la participación es por referencias y conocimiento seguro de los participantes interesados.
Su contenido apunta bien, y digamos que CA tiene lo necesario para que esta wiki se convierta en una referencia primaria de Plex, especialmente considerando su carácter abierto, es decir, consultable por cualquiera que la acceda. Algo que no es tan simple si alguien desea abordar su documentación (bookshelves) conservada en el área de Producto de la web de CA. Un aspecto importante es que la wiki completa es descargable como pdf o epub (como pdf deja un documento de más de trescientas páginas).
Esta wiki está en sus comienzos, enfocada en la versión 7.1. No dudo que a través de sugerencias y críticas se irá puliendo y enriqueciendo, hasta convertirse en una referencia primaria para quienes quieran conocer el modelador y generador, y para nuevos desarrolladores que quieran entender cómo usarlo.
Por ahora, todavía un poco parco, y con algunas inperfecciones, como considerar la explicación del uso del diagrama de acción y el manejo de entidades relacionales como parte de los componentes de System i. De todas formas, muy recomendable, especialmente esperando su enriquecimiento futuro, que eso es lo que está en la esencia de cualquier wiki.

Evaluando la comunidad oficial de Plex

En la comunidad de usuarios de CA Plex estamos atravesando la enésima modificación del sistema de intercomunicación entre el dueño del producto (CA) y sus usuarios (todos nosotros). A varios meses del cambio, ¿qué podemos destacar de positivo o negativo?
Primero lo positivo...
Mayor visibilidad: finalmente, parece que CA unifica una misma vía de comunicación con usuarios, distribuidores e incluso personal interno. No sé si a alguno de los community manager "on charge" les importa algo, pero ahora los productos de desarrollo de aplicaciones aparecen en el flujo de discusiones junto a las estrellas de la promoción del negocio. Un aspecto que a alguien podría llamarle a atención es el número de participantes en discusiones, suficientemente alto en Plex, 2E o Gen.
Acceso unificado al soporte, la documentación técnica o de divulgación. Existen mejores posibilidades de investigar la documentación de una incidencia o los artículos técnicos de formación. Parcialmente accesibles incluso en una búsqueda anónima en Internet.
Acceso externo a las discusiones de la comunidad de Plex/2E, tanto si se busca un problema determinado, como si se usan los alimentadores de noticias
Unificación de las dos líneas de colaboración: seguimiento de problemas y anuncios, y postulación de ideas de cambios o mejoras. Ahora ambas líneas de colaboración comparten la misma corriente de noticias, lo que favorece la participación de usuarios que antes quizá no eran concientes de que existía una vía directa de solicitud de mejoras. Quizá este sea el aspecto más interesante.
Y lo negativo:
Una vez más los cambios...algunos usuarios poco dados a conectarse a la comunidad, tardarán un tiempo en advertir que ya no sirven los viejos enlaces. Los alimentadores de noticias ya no funcionan, y hay que rehacer las direcciones usadas. El esfuerzo de comunicación puesto para facilitar la transición, muy escaso.
Los "community managers": si en las restantes comunidades se los ha seleccionado como a los de Plex/2E, tardaremos largo tiempo en tener una actividad de promoción de su parte. En nuestro caso, no parecen tener mucha experiencia en los productos. Por lo tanto, salvo dar hurras a la actividad de los usuarios, poco podemos esperar por ahora.
La transición de un producto de administración de la comunidad a otro, poco planeada (por lo menos para nuestros productos); adios a las etiquetas que previamente existieran asociando conversaciones con incidencias, y creo que adios a muchos documentos adjuntos. Al menos varias incidencias. Me resulta difícil entender que se planee un cambio y las incidencias de conversión queden para después.
La participación: por algunas semanas, mínima: quizá porque los usuarios debieran rehacer algún aspecto de sus perfiles, o quizá por falta de ubicación de las direcciones de cada cosa, o por el cambio en el manejo de incidencias. Luego ha aumentado, pero todavía sin llegar a la participación usual en el pasado.

¿El futuro? Espero que menos cambios formales, y más promoción y trabajo sobre los productos. En un momento tecnológico complejo y necesitado de este tipo de herramientas, esperamos más apoyo a la potenciación de nuestros modeladores y generadores de código.

Nueva dirección de la comunidad oficial de Plex

Desde hace pocos días la comunidad de usuarios de Plex/2E/Gen tiene nueva dirección. Esta es la segunda reorganización general de las comunidades de usuarios de CA. Afortunadamente, en general se han mantenido las discusiones pasadas, aunque han cambiado los enlaces, probablemente haya problemas con los adjuntos que se hayan pasado, y los feeds deben volver a cambiarse. Los perfiles de usuarios se han mantenido, así como los contactos. No veo las etiquetas asociadas a las discusiones, aunque veo etiquetas existentes.  Un aspecto positivo es que las discusiones técnicas se han entroncado en una sola corriente de entradas junto a las ideas, es decir, las propuestas de mejoras al producto. Y parece ser que existen herramientas para crear una idea a partir de una discusión.
Actualice sus marcadores con la nueva dirección.

El objeto CDO y Office: ¿obsolescencia programada?

 Revisando algún otro asunto (algún fallo ajeno en el uso de MAPI), topé con un anuncio que en particular nos afecta en más de una instalación; digamos que en general puede afectar a cualquier usuario de Plex, pero supongo que su alcance es más amplio, más allá de la estrategia propia de Plex, para cualquier instalación basada en mensajería de Microsoft. El anuncio tampoco es nuevo: refiere a Office 2010: Collaboration Data Objects (CDO) 1.2.1 no es soportado con Outlook 2010 y versiones posteriores. CDO es una librería basada en el modelo COM de Microsoft, accesible por medio de C, C++, VBA, VB, C#, usada ampliamente para el envío de mensajería en sistemas Windows. En el mismo sitio del anuncio CDO es definido como  a client library that provides a thin wrapper over Extended MAPI functionality. This library is typically used to add email messaging functionality to custom programs. This library allows those programs to perform functions such as sending email through MAPI, working with calendars, and accessing various data in Microsoft Outlook or in Microsoft Exchange.

Posiblemente el API de MAPI haya sido intermediado por el uso de CDO ampliamente desde su aparición; bien definido, bien documentado, consistente, capaz de ser invocado desde casi todos los lenguajes ejecutables en Windows, y particularmente desde las propias implementaciones de Microsoft para el lenguaje de propósito especial de Office (VBA).
Sin embargo, a partir de Office 2010, nos encontramos que CDO no es instalado, y es desaconsejado su uso para interactuar con Office a partir de esta versión, debido a cambios de arquitectura en la suite de oficina:  

Microsoft Outlook 2010 and later versions include many architectural changes to the client-side MAPI subsystem. Of particular concern are scenarios in which Outlook is configured to use multiple Exchange accounts. Also, CDO 1.2.1 is a 32-bit client library and will not operate with 64-bit versions of Outlook. Given all these factors, CDO 1.2.1 is not supported for use with Outlook 2010 or Outlook 2013, and we do not recommend its use with Outlook 2010 and later versions.

¿Podemos considerar esta decisión una violación de los principios de arquitectura del modelo COM? Una vez más, el concepto de compatibilidad y continuidad del soporte de Microsoft opta por la vía rápida: se elimina su instalación, se ralea la información y documentación a partir de ahora "legacy", y se recomienda calurosamente el cambio a la nueva versión. Microsoft tiene una solución a su patrimonio de funciones construidas usando CDO:

Programs that use CDO should be re-designed to use other Application Programming Interfaces (APIs) instead of CDO (...) Developers should use the Outlook 2010 and later object model instead of CDO 1.2.1. Also, developers can still use Extended MAPI (which requires unmanaged C++) in some scenarios where CDO was required. However, if it is possible, we generally recommend that the Outlook object model be used instead of Extended MAPI. Microsoft product support can help developer customers migrate custom programs from using CDO 1.2.1 to using other APIs. However, Microsoft will not provide support for any scenarios in which CDO 1.2.1 is used with Outlook 2010 or Outlook 2013. 

Simple, entonces: busque todos los casos en que usara CDO, y rediseñelos para usar el modelo de objeto Office. Justo cuando Microsoft está en transición entre Win32 y WinRT, para descubrir que dentro de un par de años WinRt determina otro modelo de objeto, y, sin más trámite, todo su patrimonio sea discontinuado de nuevo.
Sin duda usted podrá seguir usando CDO, en un marco limitado, recurriendo a modificaciones de la instalación, a condición de cómo administre su instalación de Exchange (vea el punto More information en la página del anuncio de Microsoft). Pero no será soportado, y cada día encontrará menos documentación para arreglárselas por su cuenta. Si lo va a seguir utilizando, tome una medida de precaución: conserve como documento off line todo lo que pueda conseguir todavía de guía de referencia y soporte de Microsoft. Como en muchos casos, pronto encontrará que las (escasas) referencias que se conserven, lo conducirán a páginas muertas. ¿CDO funciona? digamos que sí. Lo que ha cambiado es Office, y la compatibilidad hacia atrás parece que es secundaria: cambie de modelo de API. La mejor explicación acerca de las razones del conflicto de versiones la he encontrado en lo analizado por Matt Stehle, en los MSDN blogs. Matt apunta a la existencia de dos modelos de manejo de memoria: el de MAPI/CDO, y el de .NET, que pueden producir intermitentes problemas de asignación de memoria:

MAPI has its own memory management model that conflicts with and is incompatible with the .NET runtime. This the primary reason that MAPI and CDO 1.21 are not supported running in a .NET process. The common symptoms you will see are seemingly random Access Violations and very often memory leaks (especially with CDO 1.21). There is no methodology for avoiding or managing these symptoms by using interop libraries or managing references in a particular fashion in your .NET code – it just won't work.
The trap is that CDO 1.21 and .NET can "appear" to work and you can get pretty far in your dev cycle before you run into problems. Many times we see this come up in soon after a solution is released to production, in late cycle performance testing, or in a pilot program. Opening a critical case with Microsoft when you have end users complaining of crashes or project managers short on budget is not a good time to find out that your solution is unsupportable.

Matt se extiende sobre el alcance de éste conflicto, reconociendo que realmente sólo a partir de Office 2007 existen mejores reemplazos de CDO, y que por lo demás, ambos serán excluyentes (The simple answer is you either need to not use .NET or not use MAPI or CDO 1.21). Puede leer la nota completa de Matt en su blog. No se arrepentirá, especialmente si sigue la acotación que apunta Matt a lo que Patrick Reehan dice acerca de qué significa "no soportado" para Microsoft.

En nuestro caso, el impacto sería reducido (por otra parte en ningún caso los servidores de Exchange han provocado conflictos todavía), porque CDO/MAPI están sumamente encapsulados, y no conviven procesos .NET con CDO. Todo nuestro manejo de mensajería pasa por un solo objeto, y las interfases entre un modelo y este objeto son exclusivamente de datos, sin ningún condicionamiento técnico. Bastará con redefinir las actuales llamadas, adecuándolas a los nuevos requerimientos, y recompilarlo y distribuirlo. No hará falta tocar nada más. ¿Pero esto es así en todos los casos? seguramente no, y probablemente en muchas empresas habrá (o hubo) trabajo inesperado.

Actualizando Visual Studio en Plex

Esto es de particular interés para los usuarios de Plex: hay abierta una votación  para conocer el interés de la comunidad de usuarios por llevar la versión de Visual Studio a la última disponible. En la comunidad de usuarios de CA, en la sección de ideas, o informalmente en el foro de Plex. Muy probablemente  más bien funcionará como una encuesta y un sondeo de opinión. Considerando el abismo abierto entre la versión soportada actual (2005) y la versión oficial (entre 2012 y 2013), es imposible anunciar una actualización sin consultar a los usuarios. A esta altura, a los pro evidentes, hay que sumar el costo del retrabajo necesario para subir la versión. ¿Cuánto es este retrabajo? Es de interés de cualquier empresa que haya trabajado en una arquitectura con clientes WinC (o funciones servidoras WinC) participar en la discusión, y aportar su visión del impacto esperado.
(Para acceder a los enlaces debe tener un usuario registrado en las Comunidades. Si no lo tiene, regístrese)

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

Migrando a System i 7.1

En un proyecto en el que trabajo, en poco tiempo más (midiendo en meses) migraremos un conjunto de sistemas IBM i (AKA AS/400, iSeries, al menos en su base), de 6.1 a 7.1, mientras que IBM ya anuncia i 7.2 . El cambio no representa  inconvenientes mayores: probablemente no haya demasiado que tocar en aquellas aplicaciones que generamos con Plex, que básicamente no debemos recompilar ni tampoco rehacer código.Únicamente deberíamos asegurarnos de que ningún API usada o procedimiento de lenguaje de control pudiera entrar en conflicto por obsolescencia. De acuerdo a la información adelantada por IBM, los problemas no vendrían por este lado. Es casi seguro que podremos seguir trabajando todas nuestras aplicaciones RPG, sus APIs, y nuestro CLs, sin modificaciones.
En cambio, tenemos asegurado trabajo de revisión con Java, quizá el área de mayores novedades en el software incluído para la versión 7.1, ya que, si consideramos que nos movemos desde 6.1, debemos tener en cuenta que la nueva versión abandona la máquina virtual estándar de Java (esta parte tampoco nos afecta, porque Websphere 7.0 ya la usa), y utiliza sólo la propia de IBM (J9). Esto sí requiere análisis y tests para aquellas aplicaciones que no se ejecutan con Websphere.  En el caso del servidor de aplicaciones, que es el que usamos relacionado con Plex, estimo que podremos mantener inicialmente la versión 7 de Websphere, que ejecuta Java 6, pero en algún momento debemos pensar en subir su versión a 8.1, que usa Java 7. Y esto implica que también deberemos planear la migración de Plex a 7.1. No es obligatorio, ya que podríamos mantenernos como hasta ahora, pero debemos pensar que también podemos llegar a estar presionados por los cambios en Windows, de 7 a 8.
A pesar de todos estos movimientos, no es mucho lo que impacta en nuestras aplicaciones, que se mantienen con cierta holgura en estos movimientos de versiones. Más bien, lo que debemos repensar es qué cosas podríamos reenfocar, sacando provecho de las nuevas posibilidades: gran parte de los cambios se manifiestan como extensiones. Mayor es el peligro si habláramos de dependencia de Windows, ya que el paso de 7 a 8 sí apunta a un cambio de arquitectura mayor. Pero de estos inconvenientes podemos hablar mejor en otro momento.
Dany Burger, en The Four Hundered, dedica un interesante artículo a los problemas de migración de i 6.x a i 7.1 y 7.2, que me motivaron a chequear nuestros propios riesgos a futuro. Como en otras ocasiones, es de reconocer y agradecer la política de cambio y migración de IBM y el iSeries (o como lo llames), que difícilmente te deje en una situación de callejón sin salida con una aplicación antigua: se puede evolucionar gradualmente sin tirar lo que ya está hecho.

Conferencia anual de Plex, 12 de noviembre de 2013

Con algo más de un mes y medio de retraso, un breve comentario sobre la conferencia anual de Plex. Esta vez, desarrollada directamente en la sede de CA, con buena participación de usuarios y socios de negocios de Estados Unidos y América Latina, y Europa. Dos colegas estuvieron presentes, de modo que tenemos una impresión más o menos directa de las actividades.
La conferencia ha ratificado un par de novedades institucionales que habían sido adelantadas algún tiempo antes: Simon Cockayne como jefe técnico de Plex y 2E, y Daniel Short como jefe comercial (Product Manager, seguramente con más capacidad de decisión que Simon), y una más, de triste memoria, que pone Plex, 2E, ERWin y Gen, en una sola línea de productos llamada "System Z Application Development", sólo posible en la cabeza de un business manager que quiera dar una dirección única a productos "originarios" de Sterling. Afortunadamente, las actividades de los partners que abrieron posibilidades en movilidad y web son las que realmente darán sentido a las acciones de negocios con Plex.
Podríamos decir que we ha tratado de una conferencia "transicional": no hubo grandes anuncios, sino la continuidad de anticipos dados durante 2013, comenzando por la estructura de conducción, la utilización de métodos ágiles en el desarrollo y soporte de los productos, y siguiendo por las mejoras en .NET yWCF. Muchas sesiones fueron dedicadas a técnicas aplicadas sobre el producto tal como hoy es. Hay particularmente una que es muy recomendable: la doble presentación de Morten Knudsen acerca del uso de Plex en grandes y largos proyectos. Vale la pena estudiarla detenidamente.
El peso de las novedades en curso recayó sobre los socios de CA, particularmente CM First y Websydian, quienes dedicaron varias sesiones a sus avances en desarrollos web y de movilidad. Las presentaciones están disponibles, pero en un sólo paquete; una vez que lo descargue puede seleccionar la presentación que sea de su interés. Se puede llegar a las presentaciones desde la wiki de Plex, o desde el sitio de la conferencia.
Quizá uno de los puntos de mayor interés destacables durante la conferencia es la atención puesta a los usuarios y clientes de Plex/2E, algo que se ha prolongado posteriormente: Cockayne está proponiendo que las líneas futuras de desarrollos estén ligadas a los intereses de los usuarios de la herramienta, y solicitando sugerencias y estableciendo una lista de prioridades. Esto, sumado al criterio de desarrollos cortos y convalidados con los usuarios, nos asegura probablemente releases casi anuales, pegados a los intereses de los clientes.
Probablemente, en próximas entradas comentemos acerca de estas líneas sugeridas de desarrollo.
¿Esta es la mejor manera de planificar un producto? Creo que falta algo, pero en este momento, este es el plan.