lunes, agosto 15, 2016

Segunda ola de modernización en el System i

En tiempos de grandes reacomodamientos, el System i no está ajeno a esto, salvo que aceptara caer en la intrascendencia. Tras la ola de iniciales inclusiones, ahora el objetivo es mobile, escuchando a los clientes, como el artículo enlazado comenta (IBM i Fundamental Strategy Unchanged, Always Changing, Dan Burger). 
Hace ya mucho tiempo que IBM no es el motor de los cambios y tendencias tecnológicas. Aunque se debería decir mejor todavía, que el curso de los acontecimientos escapa actualmente a la voluntad de casi todos sus actores, y evolucionan (los acontecimientos) más rápidamente que la capacidad industrial de las compañías tecnológicas de marchar a su paso o adelantarse. Y sin duda este es el caso de IBM: recursos finitos de investigación, y tiempos de investigación y  desarrollo que quedan desactualizados por los acontecimientos.
Pero hay algo más...¿hasta qué punto la adopción de las nuevas tecnologías acompaña su surgimiento? ¿cuánto de lo que vemos como posibilidad es realidad?  ¿Cuántas empresas nacionales están al día, cuántas modificaron sus procesos a fondo? Probablemente se podríadecir que casi ninguna, o ninguna...lo que tenemos es una capa superior (¿o superficial?) de un puñado de aplicaciones modernas, apoyadas en una combinación, o mezcla, infernal de aplicaciones de las más variadas épocas y tecnologías. Y que a la hora de hacer una compra por el móvil, el logro de esa transacción depende de una cadena de sucesos originados por procesos de la generación anterior, o de dos , o de tres generaciones anteriores...
¿Dinosaurios? probablemente no; simplemente los tiempos del ciclo de vida de una institución (empresa final, compañia de software, la que sea) siguen un ritmo distinto a la acumulación actual de nuevas posibilidades.
Y así, el System i no escapa a esto, por su propio tipo de función.
Nota: Quizá el título de esta nota no es el adecuado. Probablemente mejor sería decir "modernización y realidad".

sábado, octubre 17, 2015

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(2). 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.

domingo, octubre 11, 2015

ERPs en el huracán

Insensiblemente, cada día, cada semana, cada año, estamos viendo conformarse cambios en el alcance de la tecnología informática, las comunicaciones y el manejo del conocimiento que marchan hacia un modelo que parece integrar todo con todo. Están quedando desactualizados todos los conceptos que por cuarenta años han regido cada disciplina vinculada al manejo de la información, y probablemente la mejor actitud ante esto sea mantenerse abiertos y atentos a las tendencias. Si la tecnología móvil incorporó en menos de una decena de años varios miles de millones de usuarios, el ya casi con nosotros Internet de las cosas promete romper todas las barreras y escenarios en que comunicación, tecnología y conocimiento aparecen asociados. Esta totalmente masiva apertura ha dejado en un terreno irrelevante la discusión por sistemas operativos, lenguajes, técnicas, recursos, y áreas de enfoque. Hoy nuestra pregunta sería: ¿qué podemos hacer, hasta donde podemos llegar?
 En el marco de estas fuertes transformaciones del manejo de la información, los llamados ERP también están siendo alcanzados: Tras haber alcanzado ayer nomás un estatus de emperadores reinantes en el mundo empresario, los actuales cambios los están recortando a jirones, ante nuevas necesidades y nuevas velocidades de respuesta. Los actuales ERPs sin duda son capaces de atender el ciclo central de grandes áreas de negocio, quizá especialmente en el mundo de las manufacturas y en el contable, pero su capacidad de flexibilizarse ante nuevas exigencias es muy baja.
Sirva esto de introducción al excelente artículo de Alex Woodie sobre este punto: Six Signs Of The Long, Slow Decline Of  ERP. Woodie habla de "declinación de los ERPs", no sólo desde el punto de vista de la empresa usuaria, sino también desde el propio interés del fabricante del software. Así, menciona seis signos de esta declinación:
  • El costo de las licencias, por resistencia de los usuarios, y por la creciente competencia de otras alternativas, especialmente desde la nube
  • La propia migración hacia la nube
  • Los interminables costos de sucesivos proyectos.
  • Las escasas novedades incorporadas (se puede decir que cada área ocupada por un tipo de ERP deviene un commodity).
  • El movimiento del enfoque hacia nichos más lucrativos (léase Big Data).
  • ...y la deconstrucción de las suites, especialmente debido a la aparición de nuevas soluciones enfocadas en áreas específicas.
 Woodie mide el impacto de la declinación del uso de ERPs en el área de su interés, los equipos de rango medio, particularmente el IBM i (AS/400 en un pasado remoto), suponiendo que una disminución de la importancia de este software traerá una caída paralela de los equipos en que este software se ejecuta. Me permito dudar de esta correlación: el universo del manejo de la información no se ha simplificado, sino todo lo contrario, y difícilmente una empresa delegará todo su patrimonio a ninguna nube, salvo que sea propia.
Hay que pensar todo de nuevo...

sábado, septiembre 05, 2015

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.

domingo, julio 05, 2015

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.

domingo, junio 28, 2015

Nuevas capacidades del System i (AKA AS400)

Se llame System i, AS400, o cualquier otro nombre intermedio, el i no es un equipo estancado, sino todo lo contrario: robusto como siempre, y evolucionado al paso de las tecnologías. Como un breve recordatorio, Alex Woodie, en The Four Hundered, enumera las nuevas características sumadas entre 2014 y 2015:
1. Native Flash Storage
IBM added support for native flash storage in the latest round of technology refreshes, which were IBM i 7.1 TR 10 and i 7.2 TR 2. This enables native use of solid state drives (SSDs) based on flash technology.
Prior to this, getting flash storage running on an IBM i-based Power Systems server was accomplished by way of the Virtual I/O Server (VIOS). Not all IBM i shops are thrilled with VIOS, which is an AIX program and can muddy the troubleshooting of performance issues. Thanks to VIOS and the overall adoption of virtualization in the IT world, there are rumblings from the natives that we've gotten too far away from the data.
But thanks to native support for flash, IBM i shops can now benefit from the ridiculous performance boost that NAND technology can deliver, especially for busy IBM i applications that are I/O bound with traditional DASD. And it can do so without going down the VIOS/AIX rabbit hole, which still looks intimidating to smaller shops.
2. Row and Column Access Control
This security feature was added with the release of IBM i 7.2 in 2014 to prevent unauthorized users from accessing huge swaths of data. As IBM's DB2 for i guru Mike Cain explains, RCAC was added at the request of IBM i customers to protect sensitive data.
"Prior to RCAC, the security scheme was provided through the object-based security measure," Cain says in this video on the RCAC Redbook landing page. "This really means that someone. . . could get access to all of the rows or records, or they would have no access to the row or file."
Since there was no prior way for DB2 for i to subset the record access--absent defining it at the application level, which leaves the data vulnerable still to ODBC/JDBC--IBM built it, and that's RCAC. "DB2 for RCAC provides a new and robust solution that allows for the governance and control of data through all interfaces, whether those interfaces are SQL or whether they're native record-level access," Cain says.
Simply put: If you need to dole out data based on a user's specific role and don't want to completely rebuild your database schema to prevent snooping, then you need RCAC, which means you need IBM i 7.2.
3. JSON
IBM added a technology preview for JavaScript Object Notation (JSON) in IBM i 7.2 TR2 and IBM i 7.1 TR10, which shipped in the spring.
JSON is a lightweight, human-readable data format that's become the default way that Web applications store and share data. Compared to XML--which 10 years ago paved the way toward self-definable data--JSON is both easier for programmers to use and faster to load.
Considering the rising adoption of JavaScript frameworks like Dojo, Ext JS, and jQuery among IBM i developers for front-end Web development, it was a natural for IBM i to add support for JSON in the database. (While JavaScript doesn't require JSON, there are advantages to using them in combination.)
The JSON Store Technology Preview that IBM shipped with the latest TRs allow JSON documents to be stored and retrieved using DB2 for i database tables. For a good primer on the three ways developers can utilize JSON, check out this recent developerWorks article.
4. Node.js
IBM unveiled support for last October with IBM i 7.1 TR9 and IBM i 7.2 TR1.
You're probably aware of how JavaScript can accelerate development of Web clients. The frameworks mentioned above bring a host of out-of-the-box UI widgets that developers can easily drop into their development environment. What Node.js does is extend that ease-of-use to the server. Node.js (or simply "Node" to those in the know) is an open-source runtime environment for server-side applications written in JavaScript. The framework has been widely adopted because it takes much of the complexity out of building and running scalable, data-intensive Web applications.
The addition of Node.js is a good example of IBM reacting to changing trends in application development (the addition of support for Ruby is another example). To learn more about Node.js, check out Aaron Bartell's LinkedIn story about his first experience with the framework.
5. REST Web Services
IBM's support for Representational State Transfer (REST) Web services, which IBM shipped in December with the group PTFs for IBM i 7.1 TR9 and IBM i 7.2 TR1, can be grouped into the same vein as JSON and Node.js: Keeping the platform relevant to a new class of developers and a new programing style.
If JSON has become the defacto data integration standard on the Web (largely replacing XML), then REST has become the defacto program integration standard for Web-based applications--largely replacing the XML-based service oriented application protocol (SOAP) that came before it.
If you want to connect your IBM i app so it can talk to hosted cloud service, such as Salesforce or Netsuite, you're going to be doing it via REST. IBM i developers who want to keep their apps current would do well to adopt REST, not only to partake of the rich ecosystem of REST-enabled services that are already out there, but to contribute back to it too.
Como se ha dicho otras veces, el problema no es el 400, sino la apertura de ideas de quienes toman decisiones sobre su uso. Usado como servidor, suele quedar atado al criterio más bien conservador en el manejo de la lógica de negocios escrita en los servidores.

sábado, junio 27, 2015

Una guía de trabajo con Plex

George Jeffcock, en su sitio relacionado con sus Stella Tools, dedica algunos párrafos a recomendar buenas prácticas en el uso de Plex. Coincidiendo con las guías de enseñanza usuales en Plex, George recomienda:
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"

sábado, junio 13, 2015

Harto de videos y ppts...

Diariamente recibo mucho material de tecnologías que me interesan, novedades, recomendaciones, y una buena cantidad de lo arribado me atrae. Pero cuando trato de analizar estos materiales, usualmente encuentro que refieren, en un 70/80 por ciento de los casos, a videos y/o presentaciones a través de secuencias de diapositivas: información rápida, a veces elaborada al galope, de la que se puede sacar poco provecho. ¿Soy una excepción que no encuentra el valor didáctico de presentar un problema en una secuencia de imágenes, en muchas ocasiones en un lenguaje distinto al tuyo? ¿O se trata de que el material no prentende ser didáctico, y mucho menos motivador para pensar, sino simplemente difusor, para generar una corriente de adhesiones...que continúen viendo videos? No niego que pueda ser un auxiliar importante cuando quieras analizar un proceso que vas aprendiendo, al modo en que un profesor o instructor ayudaría a despejar dudas sobre aspectos prácticos de algo. Pero cuando el ochenta por ciento del material de conocimiento es visual, sin duda perderás lo importante. Leer un papel, leer, permite ir adelante y atrás, desmenuzar, anotar, escribir. Ver un video sumerge en la corriente del discurso, suponiendo que el presentador mantenga el interés, y no nos debamos perder en interpretaciones de jerga extranjera ¿mirarías tres veces una presentación para entender un párrafo? ¿qué haces con una presentación de diapositivas que ni siquiera tiene el respaldo del orador explicando? ¿qué haces con las "divertidas" imagenes presentando paradojas del problema que vas a tratar, o con las "preciosas" transiciones de imágenes usuales en una presentación? ¿De qué le sirven a un orador las trasiciones divertidas mientras presenta un problema? ¿Cuál es su foco? Recuerdo que algún colaborador de Steve Jobs echaba de las reuniones a quien presentara un problema con un power point. Creo que lo comparto...la única manera en que me interesa una presentación de cualquiera de estos tipos es cuando se trata de una mínima lista de puntos a ser discutidos. Y si publico uno de estos, debería ir acompañado del texto que glosa. Quizá la ventaja del video o el ppt sea que se pueden fabricar como chorizos...Quizá a otro le sirvan, pero a mí me han simplificado la vida...de cada treinta, creo que miro uno.

domingo, mayo 24, 2015

Evolución o desajuste: un asunto crítico

De interés para usuarios de Plex; en el último tiempo, varias discusiones importantes se han desarrollado en la comunidad de usuarios en CA. Discusiones que van en dos direcciones: prometedores nuevos desarrollos, y retrasos lamentables en el soporte de nuevas tecnologías. Esta dualidad refleja probablemente la situación del producto: un gran capital en una herramienta robusta que no pierde utilidad, y una respuesta errática a los cambios tecnológicos. Puntualizo algunas de las discusiones, e invito a revisarlas, y en el caso de las ideas propuestas, a votarlas si les parecen adecuadas. Las menciono por su título:
Outlook question: la discusión abierta es acerca del soporte de WinApi, ObMapi, es decir, el sistema de mensajería, para Outlook 2013 (también se menciona Outlook 2010). El problema reside en que el API está soportado para 64 bits, pero no para 32 bits, y Plex es generado para 32 bits. Esta es la respuesta del soporte de Plex:
There is a compatibility issue between the 64-bit versions of Microsoft Outlook and other 32-bit applications. Since Plex generates 32-bit application, you will need to use the 32-bit versions of Outlook.  (remite a la explicación de Microsoft). So, if you are using the OBMAPI or WINAPI Souce Code mail APIs, then you will not be able to use the 64-bit version of Outlook 2013 with these APIs.
La solución ofrecida es usar la versión de Office de 32 bits, o usar otro código, o solicitar al equipo de desarrollo que estas APIs soporten 64 bits. El propio soporte recomienda esta última opción, que conduce a  una solicitud existente desde julio de 2014.
Sobre este asunto del atraso en el soporte de productos u opciones respecto a la evolución tecnológica actual, hay otra discusión que afecta a 2E, no Plex, pero donde valen las opiniones de los participantes, ya que podrían asociarse sin mucha dificultad también a Plex: la complejidad de plataformas y tecnologías que deberían abarcarse hace difícil mantener el paso. En el caso de Office, el problema resulta aún más claro: los cambios de arquitectura ensayados por Microsoft son capaces de hundir a cientos de proveedores de servicios que trabajan para su plataforma (partners), como sucediera con el mercado de Silverlight, y seguramente con los incipientes desarrollos orietados al cuasi difunto Metro.
Otras discusiones de importancia vienen de la sección de Ideas, por ejemplo la postulación de la generación de servicios REST sobre el System i (discusión especialmente interesante), o las dos o tres referencias a la actalización del soporte de SQL en el System i (1, 2). O incluso las postulaciones a mejoras en el soporte de RPG ILE. Todos ellos hablan de un retraso de soporte a la evolución de las distintas plataformas, que resulta prioritario resolver. Hoy la evolución tecnológica es rápida y diversa, y resulta muy difícil abarcar el espectro completo de arquitecturas, tecnologías y paradigmas. Aún para el paradigma de diseño basado en modelos, resulta difícil seguir el paso para elaborar transformaciones adecuadas a cada caso y sus interrelaciones. ¿Qué camino es más aconsejable en éste caso, el de Plex?
Desde hace años, la solución de las transformaciones para atender nuevas áreas en Plex han estado a cargo de terceros; sea socios de negocios, como en el caso de los desarrollos web, telefonía móvil, e incipientemente cloud por parte de SoftDesign (Websydian) y CM First (WebClient), o los desarrollos para XML de Simon Jasperse, o los minipatterns debidos a Peter Fabel y Luwdig Hirth, o Stella Tools de George Jeffcock. Probablemente este sea el mejor modo de poder atender, especialmente sin un elevado presupuesto de investigación, la avasalladora ola de cambios en que nos movemos.
También desde hace años, el equipo de desarrollo de Plex expone crecientemente el API que permite la interrogación y operación del modelo, sus objetos y sus métodos. Es gracias a ésto que herramientas como Stella Tools puede trabajar. Probablemente esta vía sea la mejor para el desarrollo del modelador y sus generadores. Sería muy positivo que el trabajo del laboratorio de desarrollo de Plex se concentrara en éste aspecto: los modos para extender el modelador, para extender la inclusión de nuevos generadores que puedan ser elaborados por terceros. Estos terceros podrían ser empresas interesadas en extender la generación de código final a un nuevo área, o empresas  interesadas en adecuar una extensión a sus propias necesidades. Al modo en que Xtext trabaja hoy como DSL. Creo que ésta es la salida viable de Plex en éste momento, y allí deberían centrarse los esfuerzos.


domingo, mayo 10, 2015

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.

domingo, abril 26, 2015

Qué va de un AS/400 a un System i

Aunque el lanzamiento corresponde a mediados del año pasado, la cuenta de Google+ de IBM Red Books, volvió a destacar una publicación de mucho interés en estos últimos días: Modernization Redbook has been published!. El comentario refiere al Red Book "Tools and Solutions for Modernizing Your IBM i Applications", editado en septiembre de 2014, y renovado ahora. Este libro contiene información de servicios y características del System i, pero particularmente la descripción de implementaciones de distintos socios de negocios de IBM. Este texto merece ocuparse de él, pero ahora lo que particularmente me interesa es la entrada de blog que aparece relacionada: "Modernization Redbook has been published!". Porque esta entrada, de junio de 2014, comenta un red Book que es la base de "Tools and Solutions...". Se trata del libro "Modernizing IBM i Applications from the Database to the User Interface and Everything in Between ", y éste sí es especialmente interesante, fundamental. En este texto se explica qué ha cambiado, y qué es posible hacer hoy con un System i. Realmente, mucho ha pasado entre el inicial AS/400 y su continuidad actual.
El libro tiene toda una primera parte donde habla de modernización, un aspecto especialmente requerido en entornos de AS400, en los que es frecuente encontrar cierto conservadorismo en el uso del equipo. Quizá no en general, donde el área de IT podría estar actualizado, pero sí en el área del AS400. Probablemente la propia ventaja de que pueden ejecutarse aún antiguas aplicaciones migradas de versiones anteriores de IBM (S/36, S/38 y más) tiende a mantener un ambiente que no cambia lo que funciona. Y lo mismo sucede en parte con el horizonte de los recursos humanos involucrados. Por lo tanto, la minuciosidad de las explicaciones en el terreno de la modernización, son entendibles.
Pero el resto del libro es material más que útil, destacando los nuevos servicios que el System i dispone, lo que lo hace distinto a sus orígenes:
El ambiente integrado de lenguajes (ILE), que permite interactuar entre distintos lenguajes disponibles en el equipo. A través del libro se explican distintos casos de aplicación del ILE. Es fundamental entender las posibilidades del ILE  para la explotación del equipo, por ejemplo, desde el punto de una arquitectura SOA.
Java, PHP, Ruby on Rails integrados. La disponibilidad de lenguajes capaces de trabajar para arquitecturas web, o articulables sobre múltiples plataformas, ha abierto completamente las posibilidades del equipo.
Servicios de administración de datos extendidos (data centric development). Desde el lejano inicio del DB2 sobre el AS400, las posibilidades de trabajo con la base de datos han cambiado y mejorado radicalmente. Nunca me he quejado de la eficiencia de DB2 en el AS400, pero los ajustes que se hacen sobre el ahora System i extienden su excelente servicio a las actuales necesidades de grandes bases de datos (Big Data).
El libro describe esta evolución así:
The original database designs might have come from an S/36 environment. This origin implies that the files are programs that are based on a flat file design. If the design is from the S/38 or early days of the AS/400, chances are that the database design was created one time and has lost any resemblance to that original design over time. Programmers can be good at adding a function or extending something after they do only a cursory review of the effect to the overall design. Although these designs continue to work on IBM i, neither approach takes full advantage of the power of DB2 for i.
Since the announcement of the AS/400, 25 years ago, IBM has continued to add new features and new functions to the database with each new release and technology refresh. A contemporary design is critical to take advantage of these new functions and to experience the performance improvements inherent in the updates. It is time to look at a data-centric view of development (...)

One of the most important improvements to the database over the years is the advancement of SQL. When we talk about a modern database, SQL is a requirement. This is not to suggest that native database access should be forbidden, but instead that it should use the correct tool for the job.
Traditional record access for small data sets can be effective. But, as data sets become larger, the effectiveness of native access can diminish. Additionally, your applications are required to take more responsibility for processing data across multiple tables. This processing can lead to complicated application code that can cause performance issues.
This situation is where SQL must be used. The beauty of SQL is that it uses the system or operating system versus the application. Many complicated data access routines can be replaced by SQL, which allows the system to figure out the indexes that make the most sense to retrieve the wanted data. The SQL engine on IBM i has undergone significant development focus over the past few years. The database has become better at creating and maintaining indexes to optimize your data access. The more records that you need to process, and views you need to combine, the better SQL can perform. In addition to the optimized indexing, SQL can use the multi-threading capabilities of the system without causing RPG and COBOL program (which are single-threaded) issues.
El i está abandonando definidamente el enfoque que siempre mantuvo sobre la base de datos, orientada a la recuperación de filas (orientada a registro - READ/WRITE) para adoptar el punto de vista de la orientación a sets de datos, dando prioridad al SQL. IBM  está recomendando abandonar la creación de tablas mediante DDS para hacerlo con DDL.
Este es un punto donde Plex debe actualizarse, acompañando esta "revolución copernicana" en el manejo de datos. Notablemente, Plex es capaz de generar código SQL, pero lo hace para variantes ODBC/JDBC, dando prioridad en las variantes de servidor/400 (RPG400, RPGIV, SQLRPG400, SQLRPGIV) a la "orientación a registro". No es que no se pueda explotar este cambio en Plex, pero exije un grado de intervención manual que no debería tener, dado que tiene los elementos necesarios para otro enfoque. Entre las modificaciones solicitadas por los usuarios, algunas de las más importantes se concentran en este área (generación de DDL, explotación a fondo de SQLRPGIV).
Otros aspectos del cambio en el System i son los relacionados con SOA y Servicios Web, Sevicios XML, Soporte de servidores Web, Soporte de Cloud, enlace con aplicaciones móviles...
Pero esto será para conversar en la siguiente oportunidad. Por ahora, hasta aquí.

domingo, abril 19, 2015

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.

martes, abril 07, 2015

Diez reglas para recordar (y seguir...)

Firmado por Javin Paul, un artículo que recuerda diez reglas importantes de orientación a objetos en el diseño con Java (10 Object Oriented Design Principles Java Programmer should know), que podríamos extender fácilmente a otros campos (y estoy pensando en Plex). Un pequeño decálogo, tan escueto que podríamos pegarlo en una pizarra frente a nuestros ojos, y que deberíamos repasar todos los días.
 DRY (Don't repeat yourself)
Our first object oriented design principle is DRY, as name suggest DRY (don't repeat yourself) means don't write duplicate code, instead use Abstraction to abstract common things in one place. If you have block of code in more than two place consider making it a separate method, or if you use a hard-coded value more than one time make them public final constant. Benefit of this Object oriented design principle is in maintenance. It's important  not to abuse it, duplication is not for code, but for functionality . It means, if you used common code to validate OrderID and SSN it doesn’t mean they are same or they will remain same in future. By using common code for two different functionality or thing you closely couple them forever and when your OrderID changes its format , your SSN validation code will break. So beware of such coupling and just don’t combine anything which uses similar code but are not related.

Encapsulate What Changes
Only one thing is constant in software field and that is "Change", So encapsulate the code you expect or suspect to be changed in future. Benefit of this OOPS Design principle is that Its easy to test and maintain proper encapsulated code. If you are coding in Java then follow principle of making variable and methods private by default and increasing access step by step e.g. from private to protected and not public. Several of design pattern in Java uses Encapsulation, Factory design pattern is one example of Encapsulation which encapsulate object creation code and provides flexibility to introduce new product later with no impact on existing code.

Open Closed Design Principle
Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful SOLID design principle, which prevents some-one from changing already tried and tested code. Ideally if you are adding new functionality only than your code should be tested and that's the goal of Open Closed Design principle. By the way, Open Closed principle is "O" from SOLID acronym.

Single Responsibility Principle (SRP)
Single Responsibility Principle is another SOLID design principle, and represent  "S" on SOLID acronym. As per SRP, there should not be more than one reason for a class to change, or a class should always handle single functionality. If you put more than one functionality in one Class in Java  it introduce coupling between two functionality and even if you change one functionality there is chance you broke coupled functionality,  which require another round of testing to avoid any surprise on production environment.

Dependency Injection or Inversion principle
Don't ask for dependency it will be provided to you by framework. This has been very well implemented in Spring framework, beauty of this design principle is that any class which is injected by DI framework is easy to test with mock object and easier to maintain because object creation code is centralized in framework and client code is not littered with that.There are multiple ways to  implemented Dependency injection like using  byte code instrumentation which some AOP (Aspect Oriented programming) framework like AspectJ does or by using proxies just like used in Spring. See this example of IOC and DI design pattern to learn more about this SOLID design principle. It represent "D" on SOLID acronym.

Favor Composition over Inheritance
Always favor composition over inheritance ,if possible. Some of you may argue this, but I found that Composition is lot more flexible than Inheritance. Composition allows to change behavior of a class at runtime by setting property during runtime and by using Interfaces to compose a class we use polymorphism which provides flexibility of to replace with better implementation any time. Even Effective Java advise to favor composition over inheritance.

Liskov Substitution Principle (LSP)
According to Liskov Substitution Principle, Subtypes must be substitutable for super type i.e. methods or functions which uses super class type must be able to work with object of sub class without any issue". LSP is closely related to Single responsibility principle and Interface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality ,and does violated LSP. In order to follow LSP SOLID design principle, derived class or sub class must enhance functionality, but not reduce them. LSP represent  "L" on SOLID acronym.

Interface Segregation principle (ISP)
Interface Segregation Principle stats that, a client should not implement an interface, if it doesn't use that. This happens mostly when one interface contains more than one functionality, and client only need one functionality and not other.Interface design is tricky job because once you release your interface you can not change it without breaking all implementation. Another benefit of this design principle in Java is, interface has disadvantage to implement all method before any class can use it so having single functionality means less method to implement.

Programming for Interface not implementation
Always program for interface and not for implementation this will lead to flexible code which can work with any new implementation of interface. So use interface type on variables, return types of method or argument type of methods in Java. This has been advised by many Java programmer including in Effective Java and head first design pattern book.

Delegation principle
Don't do all stuff  by yourself,  delegate it to respective class. Classical example of delegation design principle is equals() and hashCode() method in Java. In order to compare two object for equality we ask class itself to do comparison instead of Client class doing that check. Benefit of this design principle is no duplication of code and pretty easy to modify behavior.
Y volviendo sobre la idea de su aplicabilidad en Plex, sin duda lo es. En algunos casos fácilmente entendible, (Favor Composition over Inheritance, Encapsulate What Changes, DRY,  Favor Composition over Inheritance) y en otros casos, después de luchar contra la vía fácil de hacer las cosas (Programming for Interface not implementation). Solo veo difícil implementar Dependency Injection. Y cuando me refiero a aplicabilidad, lo hago a nivel del modelo, no a nivel del código generado, donde su aplicabilidad está asegurada.
Plex, como otros productos, admite distintas interpretaciones, distintas formas de desarrollar. Aplicar principios de OOD permite explotarlo en forma más productiva, potenciando sus características. Luchar por no usar una hoja de ruta rutinaria favorece resultados consistentes y duraderos.