domingo, septiembre 05, 2021

Utilidad de The Java Version Almanac

 Usualmente trabajo en Java 8, (como parte de otros lenguajes). La versión 8 es obligatoria como intersección de los distintos productos que se combinan en nuestro desarrollo (Plex, Websphere, C++, RPGIV, OS/400). Francamente, podríamos pasar a Java 9 sin problemas reales, pero sería ir un paso más allá de lo que el soporte de Plex reconoce. Es probable que terminemos haciéndolo durante el año, o poco después, de todas formas. Lo que parece un gran atraso respecto a la versión corriente (Java 15/16) y las versiones bajo desarrollo (Java 17/18), si consideramos que Java 8 es por ahora la anteúltima versión estable (LTS), seguida por Java 11, y en espera de Java 17. El sistema adoptado por Oracle de desarrollo de Java en versiones con pequeños cambios graduales, favorece el avance de versión analizando el impacto que puede tener el paso a la siguiente, considerando los releases mayores como objetivos principales. Sobre el plan de desarrollo de Java, dice Oracle:

For product releases after Java SE 8, Oracle will designate a release, every three years, as a Long-Term-Support (LTS) release. Java SE 11 is an LTS release. For the purposes of Oracle Premier Support, non-LTS releases are considered a cumulative set of implementation enhancements of the most recent LTS release. Once a new feature release is made available, any previous non-LTS release will be considered superseded. For example, Java SE 9 was a non-LTS release and immediately superseded by Java SE 10 (also non-LTS), Java SE 10 in turn is immediately superseded by Java SE 11. Java SE 11 however is an LTS release, and therefore Oracle Customers will receive Oracle Premier Support and periodic update releases, even though Java SE 12 was released. (en It's time to move to Java 17, Johan Janssen, 27 de agosto de 2021, Java Magazine)

Marc R. Hoffmann y Cay S. Horstmann han desarrollado un cuadro que despliega el inventario de todas las versiones de Java existentes, su soporte, y el análisis de los cambios existentes de versión a versión, a nivel de clase y método. Este cuadro es un auxiliar imprescindible a la hora de planear una meditada actualización a niveles superiores. Se trata de un gran trabajo, que al menos a mí me resulta de consulta obligatoria. Ojalá otros productos relacionados tuvieran un cuadro similar (estoy pensando en Apache POI, donde suelo necesitar la inferencia y el análisis de casos para concluír qué debo usar).

The Java Version Almanac, javaalmanac.io


 

martes, agosto 31, 2021

Moviendo una aplicacion a la nube

 Días atrás leí con interés un artículo de Jonathon Henderson, de Scott Logic, describiendo detalladamente un proyecto de conversión de una aplicación descripta sin entrar en detalles como "monolítica", a un conjunto de servicios y/o aplicaciones back y front end que la reemplacen, basado en AWS. Henderson describe su proceso de descubrimiento y reconocimiento de los mecanismos y recursos que fue necesitando, y su proceso de entendimiento y dificultades que pudo o no resolver: una bitácora de trabajo más que útil. Esta es su descripción del proyecto:

I had the pleasure of picking up Scott Logic’s StockFlux project with the same fantastic team as my previous project, which consisted of 3, very talented frontend developers and myself as the lone backend developer.

The frontend team had the task of transforming the existing StockFlux application to use the bleeding edge of the OpenFin platform, which incorporated features defined by the FDC3 specification by FINOS.

This involved splitting StockFlux into several applications, to showcase OpenFin’s inter-app functionality such as snapping and docking, as well as using the OpenFin FDC3 implementations of intents, context data and channels for inter-app communication. It also involved using the FDC3 App Directory specification to promote discovery of our apps using a remotely hosted service, which is where I come in.

Henderson describe fundamentalmente su trabajo de backend, sin entrar prácticamente en el trabajo del frontend, pero de todas formas es una buena y estimulante descripción de aprendizaje y evaluación de caminos posibles.

Esta es su enumeración de objetivos de su propio trabajo:

  • Building an FDC3 compliant App Directory to host our apps and provide application discovery.
  • Building a Securities API, with a full-text search, using a 3rd party data provider.
  • Providing Open-High-Low-Close (OHLC) data for a given security, to power the StockFlux Chart application.
  • Creating a Stock News API.
  • Building and managing our infrastructure on AWS.
  • Automating our AWS infrastructure using CloudFormation.
  • Creating a CI/CD pipeline to test, build and deploy changes.

Una vez completado el proyecto, con una idea clara de los puntos fuertes y débiles de su desarrollo, y del soporte de AWS, Henderson se siente conforme con lo hecho. No obstante, deja una observación que debe ser tenida muy en cuenta:

One thing I’m still relatively unsure about is the idea of vendor lock-in. By basing an application around their specific services, we effectively lock ourselves into AWS, which makes our applications less portable. While building the StockFlux backend services I made an effort to abstract things in such a way that would allow us to add support for services offered by other providers, to reduce our dependency on AWS. On the other hand, locking into one vendor doesn’t have to be a bad thing - by committing to use AWS (or another provider), we can explore and utilise the vast array of services that are on offer, rather than restrict ourselves to using as little as possible to promote portability.

Es decir, permanece casi por completo en manos de su proveedor, sus tarifas, y evolución de sus planes.Sin duda, una particularidad de Cloud services que debe ser pesada con cuidado. Especialmente cuando se translada no una aplicación pequeña y volátil, sino algo de importancia y vasto.

domingo, agosto 29, 2021

Lo suscribo...

 cómo ser el peor...

Visión del bosque

 Cuando observo, sea en las publicaciones que llegan a mis manos, o sea en lo que veo y oigo a mi alrededor, hay algo que me suena mal, y que me deja en ascuas. Veo los árboles, pero no veo el bosque, por ningún lado. 

Es usual hablar de CI/CD, de n variantes de Agile, de microservicios, de n variantes de JavaScript, de Cloud, de n lenguajes -sin considerar el contexto de aplicación-, de sockets, de web components, etc, etc. Podríamos llamar a estos desarrollos "material diario de trabajo", en algún caso metodológicos y en otros instrumentales. Pero no veo mucho foco más allá de estos elementos y medios de desarrollo. Ni siquiera se trata de arquitecturas. Se enfoca el proceso de desarrollo en automatizarlo y entregar a producción con velocidad y continuidad diaria, se espera independencia total entre componentes, se espera que cada componente pueda construírse encapsulado y sin dependencias de ningún otro. Pero no veo el bosque, no veo el plan general. Seguramente no se trata de que no existe, sino que se piensa y trabaja en los detalles. StackOverflow o muchos otros sitios similares no ofrecen ese tipo de visión, y mi pregunta es si todos esos desarrolladores que exponen o investigan sobre problemas de explotación de su instrumental diario de trabajo, tienen ese punto de vista. Me pregunto si el enfoque en microservicios o enfoques similares, el trabajo en pequeños grupos, la utilización de equipos de trabajo en sitios remotos y opacos, si no implican que el bosque está visto en un pequeño, pequeñísimo grupo de ¿arquitectos? ¿líderes de proyecto? ¿responsables de producto?,  y el sentido se va perdiendo desde las reuniones "agiles" hasta el último eslabón de la cadena, allí donde se escribe el código.

domingo, agosto 08, 2021

Microservicios y sentido común

 A propósito de microservicios, comentados en otras recientes oportunidades, un par de observaciones de Mika Yeap en Medium. Aquí se menciona el monolito más como una antiguedad que como una aplicación que integra todo en un sólo ejecutable. Esto tiene más sentido y va en la dirección en la que los mocroservicios actúan, o deberían, cuando corresponda.

Una razón que Yeap reconoce es la escala. Arquitectura distribuida y microservicios para atender el crecimiento de elementos y operaciones en el sistema del que se trate. Pero al hablar de escala, habla de escala global, de decenas o centenas de millones de nodos participantes:

There’s a multitude of reasons you’d need to use distributed architecture when you get big enough. The catch is most of us will never get big enough. I mean, how close are you to Amazon’s numbers? Or how about Netflix? That’s what I thought.

Yeap recuerda que trabajar con microservicios no es simple, y requiere disponer antes una organización robusta, disciplinada, con conocimiento y recursos. Aún así, recomienda pasar a una arquitectura distribuida sólo cuando sea imprescindible, y conservar "el monolito" mientras sea viable: 

...it’s best to challenge this beast only if you’re prepared. Skills. Talent. Organization. You need lots of things in the right flavor to do this well. If you think you can show some engineers a couple keynotes then send them off to split all the things, you’re in for a nasty surprise. My team and I weren’t prepared, so I would know. I mean, what does a startup without product-market fit or money have to offer against microservices? Just a month’s supply of ramen to feed five people. In other words, not much but goodwill and some elbow grease. Which wasn’t enough.So as far as I’ve learned, you should only be building microservices if you’ve got a gigantic user base, or the resources to support the specialized development. And even in the first case, you don’t necessarily have to go distributed immediately. In fact, even AirBnB was powered by a monolith until just recently. A monolith written in Ruby on Rails, no less. And it seems to me that their product worked just fine.

Yet many people truly believe distributed architecture is a superior alternative to a monolithic one. People actually think they’re two equal solutions to the same problem. Which is absurd, since they’re actually solutions to different problems.

...Y recuerda que la arquitectura distribuida no es simple, en absoluto. Podemos decir que cada punto que merece foco en su implementación requiere soluciones complejas. Pone como ejemplo las transacciones distribuidas:

Microservices promise to solve all sorts of problems, depending on who you ask. When in reality, they only exacerbate them when you don’t know what you’re doing. How? Well, just two words can send chills down any microservice veteran’s spine: Distributed transactions. How’s that for a nightmare? I promise you, once you have to configure orchestration-based sagas just to update one property on a single object, you’ll be begging for a good old boring monolith.

En fin, microservicios suena genial, pero antes de emprenderlos, piense y haga números.

 


sábado, agosto 07, 2021

Unas recomendaciones generalizables

 Existe una verdad publicada, y existe una vida real. La verdad publicada está siempre en la cresta de la ola, convirtiendo en el non plus ultra a la última invención presentada. Y esto es especialmente, fundamentalemente válido en el universo de la tecnología. Se afirma que una tecnología determinada debe ser adoptada ya, porque tiene un efecto x, y soluciona un problema z "como nunca hasta ahora". Sucede como las invitaciones de todos los proveedores de servicio de Internet y telefonía: si le hiciéramos caso a todos, deberíamos reemplazar nuestro contrato de servicio una o dos veces por semana. Por eso aprecio las reflexiones de un veterano en el desarrollo de aplicaciones. A veces, el rey está desnudo.

Las recomendaciones de Beau Beauchamp se dirigen a quienes desarrollan en la categoría de Javascript, pero se pueden extender, cambiando algunos nombres, a otras categorías. 

En primer lugar, su presentación:

I’ve been a web application developer for over 20 years. I’ve seen all kinds of UI libraries come and I’ve seen them go. I’ve been in the industry long enough to know that just because a framework is new and cool and “OMG! Everyone cool is using it!”, doesn’t mean you should use it too.

Speaking from a purely enterprise perspective, which is probably the same perspective you should be looking at if you plan on building the next great SaaS app, you should be thinking long and hard about incorporating any kind of library or UI framework into your app.

Right now you’re small, nimble, you code things in record time and push to production with a minimal number of steps. You’re probably not writing tests, or very few, and all of your builds are done automagically locally.

But if you get successful, really successful, like with hundreds of developers working on your app kind of successful, all of that is going to change. You are going to become an enterprise; and in the enterprise, we do things very differently in the “real world” than you do in the “startup world”.

 Su lista de recomendaciones se hacen dialogando contra lo que se pudiera practicar en una pequeña "startup". Cambie el destinatario por otros. Hay muchos candidatos. 

La primera recomendación:

Cualquier cambio es costoso

Every step you add into the deployment process costs you time and money in ways you cannot see when you’re a small startup.

If you unwisely choose the technology stack for your app, especially the UI, it’s going to take a tremendous amount of resources to rip it out and update it

 Evite tecnologías de moda que se actualizan demasiado rapidamente, o que vienen y van

UI is notorious for flavor-of-the-day UI libraries and frameworks. Handlebars, React, Vue, AngularJS, Angular 2, 4, 5, 6, 7, and now fucking 8. All in the span of what—6 years? I’m sure there are bunch of others I’ve not even heard of yet.

“Angular is not a fad, Beau.” Sorry, it is. In the enterprise you cannot be changing out libraries and updating shit this fast. You won’t have the budget or the resources (“resources” is enterprise-speak for the people who will now hate you).

Each time some library or framework “updates” or changes versions, it costs you money.

Costo versus reales beneficios

Think about which UI framework you’re thinking of using in your project or next project. What is the framework really doing for you? Is it saving you time or just giving your application some cool “whiz-bang” features?

“It gives us model and DOM binding! A huge time saver.” Fine, you can do that with a jQuery plugin that you don’t have to compile. Next?

“It gives us an MVC on the front end with model-bound templates for a SPA (single-page application).” Fine, but this is not saving you time; in fact, it’s costing you more time in building pages, compiling, and SPA’s are terrible if you need real SEO and accurate analytics.

At the end of the day, by the time you are done installing all of the crap that you need to actually run the super-really-cool fad-tech UI framework, it’s not easier at all, and all you have done is saddled your enterprise team with hours and hours of frustrating local setup and configuration and IDE integration. It’s nonsense.

Yea, we do it; but it’s NOT easier. I’ve seen enterprise devs saddled with setting up the new wiz-bang technology spend literally weeks working out the bugs in their development environments because someone decided to install a new “framework”.

And at the end of the day, the UI framework, much more of a pain in the ass, much more difficult to debug, than it was helpful in achieving a good clean easy-to-mange front-end.

Diga no a compiladores de UI. Mantengo este punto porque está en su lista, y tiene importancia en este caso. Aquí, la generalización está en qué línea de desarrollo recomienda: 

I once interviewed with a really big video game company. You know what their development policy was changing to? Plain ECMA (JavaScript) and CSS. No compilers. No CoffeeScript. No TypeScript. They even ripped out jQuery. I was impressed.

Now why were they doing this? Because they needed to save time and money. Over the years developers had come into their teams, added in all kinds of wiz-bang fad tech into their UI, and then left. Now their teams were saddled with all of the UI garbage that was costing the company millions in developer hours each time Angular or whatever SPA library had an update or an upgrade. We’re talking about touching literally millions of lines of code and tens of thousands of files across the enterprise.

I totally understand why they junked all of it. Now, I personally wouldn’t junk jQuery or Bootstrap, but those don’t need to be compiled to run; and jQuery isn’t updating every 5-minutes either. You can usually update without causing huge regressions, if any at all.
 
A la conclusión de Beau podríamos agregarle otros causantes...

The reason these fad-tech UI libraries even exist is because of bored engineers working at big tech, like Google, Facebook, Twitter, etc. But at the end of the day nothing works better and is easier to debug and maintain than just pain JS and native CSS.

¿Monolitos? ¿Qué monolitos?

 Si atendemos a las definiciones de sus propios favorecedores, creo que se aboga por microservicios apoyándose en una entelequia que poco tiene que ver con el mundo real de las aplicaciones corrientes. Tomado de A Deep Dive Into Microservices vs. Monolith Architecture, por mencionar un caso que dice apoyarse en los estándares (aunque no menciona a Martin Fowler):

Monolith simply refers to one block containing all in one piece. According to Wikipedia, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

Y siguiendo su referencia a Wikipedia:

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

A monolithic application is self-contained and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function.[1] Today, some personal finance applications are monolithic in the sense that they help the user carry out a complete task, end to end, and are private data silos rather than parts of a larger system of applications that work together. Some word processors are monolithic applications.[2] These applications are sometimes associated with mainframe computers.

In software engineering, a monolithic application describes a software application that is designed without modularity.[citation needed] Modularity is desirable, in general, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement.

Modularity is achieved to various extents by different modularization approaches. Code-based modularity allows developers to reuse and repair parts of the application, but development tools are required to perform these maintenance functions (e.g. the application may need to be recompiled). Object-based modularity provides the application as a collection of separate executable files that may be independently maintained and replaced without redeploying the entire application (e.g. Microsoft "dll" files; Sun/UNIX "shared object" files).[citation needed] Some object messaging capabilities allow object-based applications to be distributed across multiple computers (e.g. Microsoft COM+). Service-oriented architectures use specific communication standards/protocols to communicate between modules.

In its original use, the term "monolithic" described enormous mainframe applications with no usable modularity.[citation needed] This, in combination with the rapid increase in computational power and therefore rapid increase in the complexity of the problems which could be tackled by software, resulted in unmaintainable systems and the "software crisis".

Es decir, si vamos a considerar "monolito" a una aplicación que en un solo ejecutable procesa los datos, define toda la lógica, y contiene la propia interfaz de comunicación con el mundo, probablemente haya que remontarse a 1970 o poco más (the term "monolithic" described enormous mainframe applications with no usable modularity).  Con seguridad, hace cuarenta años que ese paradigma no existe, salvo que incluyamos en él a las corrientes "apps" moviles. Como el propio artículo de Wikipedia menciona, simplemente la modularidad y la posibilidad de mantener una aplicación separada por responsabilidades de servicio existe no menos que desde los 80 del siglo pasado, y más atrás desde que lenguajes de alto nivel como el COBOL existen. Sólo un mal diseño, pésimo diseño, podría poner  todos los aspectos de una aplicación en un solo componente: podemos decir que existen otros modelos distintos que practican la modularidad y la separación de responsabilidades desde mucho antes de que se hablara de microservicios. 

Oponer Microservicios/Monolitos es sesgado y parcial. Otras arquitecturas/tecnologías se han desarrollado y perfeccionado para combatir los indudables perjuicios de un "monolito". Si vamos a la discusión del artículo en Wikipedia (siempre hay que ir a la historia y a la discusión), los observadores críticos del artículo así lo hacen ver:

The article lacks proper references and has a down view of the concept instead of explaining what it is. The article is also very focused on explaining what modules are and why they are good, getting out of the topic. I would go a step forward and say that this article has wrong information. 

El artículo de Wikipedia habla de "data silos". Este es un punto muy interesante y hay que verlo por separado, en otro momento. 

Pero establecer un paradigma opuesto que sea la panacea, requeriría un poco más de trabajo. Podemos decir que contra esa figura de "monolito" se ha trabajado durante treinta o cuarenta años (por ejemplo OOD/OOP), antes que se proclamara que los microservicios  son la solución.

 


sábado, julio 31, 2021

Elemental, Watson

 Leyendo publicaciones técnicas hoy, tan pronto como levantan la vista al nivel de arquitectura, parecería que lo único que existe es una arquitectura basada en microservicios, y lo demás es monolitico y repudiable (o peyorativamente, simplemente monolitos de la prehistoria). Dice Atul Mittal, en Medium:

Is it always necessary to have Microservice Architecture instead of Monolithic Architecture?

The answer is NO, BIG NO. You should very understand the efforts and the value your product brings in. Generally, at first, implementing Microservice Architecture is a very tedious task, you need to have a separate Team/Architecture for each component that you need to have in your Application and a lot of thought process goes into that which might not be a viable option for small companies or Application built in very less budget, so there comes a saviour way to create Applications in “Monolithic” fashion or you can also say “traditional” way of creating Applications. If there are not so many components in that case also, you can think to adopt a “Monolithic’ way of doing things. But keep in mind, to modularize your application as much as possible so that later in case you want to redesign it in a “Microservice” way you don’t face many challenges in doing so.

domingo, julio 18, 2021

Balance y reinicio

 Cuando éste blog se creó, y más aún su página de orígen, las tendencias de desarrollo de software y las arquitecturas para las que se trabajaba eran muy distintas. Hablabamos entonces de cuarta generación del software, pero hoy deberíamos hablar de quinta generación por lo menos. Nuevos procesadores, nuevas memorias, nuevos discos -por hablar de lo mínimo-, nuevas posibilidades de otras arquitecturas. Hoy los actores son otros: Amazon, Facebook, Netflix, Twitter, Google, empresas cuyo negocio no es el software, pero que potencian radicalmente su uso, la investigación y adopción de recursos, la proposición de nuevas tecnologías, nuevas metodologías. Hoy se atacan nuevos desafíos, se resuelven problemas de una escala nunca antes vivida. Las empresas que impulsan el replanteo del manejo de recursos y arquitecturas, son de un tamaño global, donde se habla miles de millones de conexiones. Esa escala universal puso sobre la mesa la posibilidad de explotar recursos de otra manera, apareciendo con fuerza la nube, la virtualización, Internet. Nube para ejecutar aplicaciones, para desarrollarlas, para rentarlas, para escalarlas. Y el estallido en curso de IOT, a una escala que pocos especialistas hubieran calculado hace dos décadas.

En el curso de los últimos seis o siete años, el cambio de escenario ha sido extraordinario. Apple mantiene el paso, Microsoft lucha por ello, IBM hace esfuerzos por no quedar atrás. En cierto modo, salvo tres o cuatro de los nombres que enumeramos antes, se podría decir que no existen empresas dedicadas al software o al hardware que no hayan sido o puedan ser compradas. Entre ellas, la empresa que sostiene el producto con el que he trabajado y trabajo (CA, hoy comprada en bloque por Broadcom). Si en el pasado tendí a pensar que el desarrollo de productos y paradigmas era darwinista, hoy debería precisarlo, como la propia realidad de la investigación arqueológica ha hecho con Darwin: el desarrollo de la tecnología sigue el camino del más fuerte, donde el más fuerte es el que puede hacer la oferta hostil o concertada más grande sobre cualquier producto. Si el nacimiento del nuevo siglo se caracterizó por la aparición de innumerables startups, el avance de esta segunda década ha evolucionado con una progresiva concentración del mercado y los competidores. En muchos casos, el modelo de startups se convirtió en "generar una idea y venderla".

En fin, después de "dormir" por demasiado tiempo, espero volver a escribir otras reflexiones. En esta indudablemente nueva era de la tecnología en todos los frentes, trataré de usar la figura de Jano, mirando atrás y mirando adelante. Trataré de compensar el largo interregno.

lunes, abril 19, 2021

Volviendo a la actividad...exigido por Feedburner

 

Por mucho tiempo he dejado de publicar entradas en este blog. Creo que debo una explicación, y Feedburner me ofrece una oportunidad de ocuparme de ello.

Feedburner, el alimentador de noticias que uso desde hace tiempo, dejará de proporcionar el servicio de envío por correo de las novedades del blog. Según ha adelantado, desde Julio próximo. Espero reemplazar este servicio tan pronto decida una alternativa. Puede ser también un buen momento de pensar en otro modo de usar Blogger, o reemplazarlo. Google tiene una larga trayectoria de soporte condicional de sus productos, y es conveniente no descansar sólo en sus servicios...o no descansar en absoluto en ellos.

De modo que este blog deberá tener un retoque en sus servicios, y quizá no sea uno menor. Veremos qué posibilidades existen.

...Y además, será una oportunidad de volver a dedicarle tiempo, y justificar la ausencia.

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.