lunes, abril 21, 2014

Migrando a System i 7.1

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

domingo, abril 06, 2014

Incorporando recursos móviles al horizonte de trabajo

Este fin de semana leí un artículo especialmente interesante de Matt Baxter-Reynolds en ZDNet, que quise conservar aquí, para uso posterior, por sus sugerencias en el enfoque a la hora de definir qué devendrá aplicación móvil, y qué no, o no tendrá relevancia.
Do you remember a time before we used to talk about "mobile"?
In reality, it's only been a few years. You don't actually have to go back that far to find a world where mobile was unusual, where the only way normal people got the internet was through a PC that was physically wired into the network. First we got Wi-Fi, then we got cellular data, but mobile was always distinct, always secondary.
Now we're operating in a world where there is no distinction. Plus it's not like mobile has "taken over" and normal desktop computing is in second place. What we're seeing is a world where a connected device is a connected device, regardless of its classification.

Differences

The difference between a non-mobile device and a mobile device is that a mobile device is one where it can be used whilst you're moving, whereas a non-mobile device is one that can be moved from place to place. This is primarily about utility. When you need to interact with a non-mobile device, you have to go through a set-up process, sit down in front of it, and start your activity.
What people want when they engage with mobile is to be able to access their data, and reach out to people in their social networks, without having to go through this specialised set-up process.
If we're particularly looking at enterprise use, a user may choose to use mobile over non-mobile for a number of reasons. For one, it may not be easy to set-up a laptop where they happen to be in space and time -- e.g. a parent dropping their kids off to school replies to an email whilst waiting around. Or, it may just be more of a hassle than what it's worth -- e.g. having a quick look at whereabouts in the city their meeting the next day happens to be during an ad break in a favourite TV show.
In these examples, there is no clear delineation between a "mobile" and "non-mobile" task. What we're looking at is choice in how something is done. The fact that we now use operating systems and form factors that are new is simply an accident. Has Microsoft moved faster into the mobile space, beating Apple and Google, we would have been using Windows as a primary mobile OS too, rather than what we have today where we have this split of operating system use that follows the split of form factor.

Unhelpful

In business what we have today is that people tend to say "We need a Mobile strategy". In that statement, "Mobile" is very much though of as having an upper-case "M".
This is an unhelpful approach. Thinking about "Mobile" (as opposed to "mobile") tends to focus the discussion around technology, whereas it's important when thinking about post-PC to think about the sociological angles first.
There's all sorts of reasons why it's helpful for certain types of professionals to be able to reply to emails whilst dropping their kids off at school. This is after all why BlackBerry became a successful business. The most obvious one is that it allows the user to do something then and there, getting it off their radar, rather than having these trivial "I wonder if…" and "I need to…" tasks gumming up their brains.
BlackBerry is very interesting here because within the enterprise they solved this problem ahead of anyone. BlackBerry invented business-oriented post-PC way before Apple did, simply through this ability to open up access to company systems to certain types of individuals. Specifically, the company system that they opened up was email, seconded by scheduling, and contacts.
What BlackBerry actually did was hit the only really obvious part of "mobile" when it comes to enterprise. If you talk to people who want to take advantage of BYOD, or want their employer to buy them a smartphone and/or tablet, as soon as you have email, scheduling, contacts, and web browsing covered, you have largely done everything that the user wants.
This is part of where thinking about "Mobile" gets stuck. Within the business sphere, there isn't really that much to do other than those basic things. If you focus on "Mobile", all you do is fiddle around the edge of that basic problem.

Alternatives

So if you're a CTO/CIO and you're in the mood for invention and innovation in the mobile space, what do you do?
If you think about "Mobile" as opposed to "mobile", you're going to look at what can be done with the technology. Moreover, you're going to look at what is safe (i.e. what your peers manage to make work), and you're going to respond to what you're being asked (e.g. "I want to reply to emails when I'm dropping the kids off at school.")
If you think about "mobile" as opposed to "Mobile", you're still in danger, as you'll be putting the cart before the horse. "Which opportunities can be delivered best through a smartphone?" is something you may ask.
Asking the question in that way puts up an artificial technical barrier to what you're trying to do. The end user doesn't care if they are mobile or not mobile when they're using what you're provided. What they do care about is that it becomes a tool that fits in with everything else that they have going on.
Perhaps one day that tool is one that they'll want to use in the office at a PC. The next day they might want to use it on a laptop at home. The day after they'll want to access it via their smartphone on a train.
Another danger here is in how businesses buy systems. Going out into the market and asking for "mobile" narrows your options. What users want is systems that are flexible and allow anytime, anyplace, anywhere working. What you need to ask for is systems that offer that flexibility.
The trick with this is to simply ignore "mobile" as a thing -- simply don't think of mobile devices as anything special.
After all, there is no "mobile".


domingo, marzo 16, 2014

Efectividad en aplicaciones móviles

Releyendo los 12 tips para crear un sitio móvil amigable (12 Tips for Creating a Mobile-Friendly Website) recomendados por Jennifer Lonoff Schiff en CIO...
Algunos de los tips son previsibles y conocidos, alguno difícilmente realizable (Don't go overboard with Java[...script?];  "consider replacing bulky JavaScript libraries like jQuery Mobile with standalone JavaScript"). Pero en conjunto, no deja de ser una buena guía.
Detrás de la simplicidad y síntesis requerida por una aplicación móvil hay un monto de trabajo y conceptualización superior al usual "en otras eras" del desarrollo de aplicaciones, particularmente basados en dos características especialmente dadas en ellas: la vida de una aplicación puede ser considerablemente corta, y debe prevenirse su visualización sobre un número alto de clientes, formados por dos dimensiones concurrentes de actores: sistemas operativos diversos, y visualizadores (browsers) diversos. Y las diferentes versiones de sistema operativo y visualizadores...Sólo puede salvarse de esta matriz de conformidad una empresa que desarrolle aplicaciones para su propio uso...y fuerce el uso de un producto y una versión.
¿Es posible encarar una serie de proyectos móviles sin contar con un marco de recursos que simplifique el trabajo de desarrollo?
Pero un marco tal, en muchos puntos entrará en conflicto con este tipo de recomendaciones, fundamentalmente aquellas que hacen a la construcción en sí misma. En mi caso, trabajando con plantillas de Webclient, existe una oportunidad de refactorización, en la propia capa intermedia. Webclient recurre a Dojo (aplicaciones web) o Sencha (aplicaciones móviles). Si bien técnicamente podría recurrir a javascript personalizado, mucho más económico y adaptado a la recomendación ("Avoid excessive JavaScript in your mobile websites where possible, because it runs differently across different browsers and devices," says Hume. "Even different models of the same phone can often behave quite differently when it comes to JavaScript"), esto requeriría algo así como reinventar la rueda, dedicando un tiempo precioso. Más económico es revisar las propias plantillas cuando resulte necesario, y buscar medios de simplificar su solicitud de servicios del marco Dojo/Sencha. Un compromiso entre resultado final y optimización.

viernes, marzo 07, 2014

Retraso de infraestructura móvil en Argentina


Este martes, La Nación publica un editorial sobre infraestructuras de telefonía móvil en Argentina, a propósito del Mobile World Congress de Barcelona. El editorial destaca la creciente distancia entre la evolución de la tecnología y su estado en Argentina, ya no sólo respecto a los países de la primera línea de desarrollo y adopción, sino también respecto a sus vecinos regionales. Una debilidad estructural y estratégica que tiene que afectar profundamente a cualquier plan nacional que se proponga como centro de negocios en servicios de software. Lo esencial dicho:
En estos días, Barcelona ha sido el escenario ideal para la cumbre global de la industria de la conectividad móvil, el Mobile World Congress (MWC, por sus siglas en inglés). Y aunque visto desde afuera y por los no iniciados en el tema, el encuentro pueda parecer todavía del futuro, no lo es. Se trata del presente bien presente, el mundo de la gran tecnología sobre el que se asienta un cada vez más pujante negocio digital.
Lamentablemente, la Argentina parece estar muy lejos de todas estas novedades, tanto de las tecnológicas como de las comerciales, y, paradójicamente, a pesar del entusiasmo con que los argentinos abrazamos todas las innovaciones. Efectivamente, una de las certidumbres que confirmó este encuentro mundial es que nuestro país, en éste como en otros temas, no tiene planes a la vista para mejorar la tecnología para celulares y, por ello, está cada vez más atrasado en América latina. Por ejemplo, fue el único de la región que no anunció la adopción de la tecnología sucesora del 3G, la 4G LTE, que permitiría mejorar el acceso a la Web desde teléfonos móviles. La adopción de este estándar es clave para superar los recurrentes apagones que afectan a las comunicaciones móviles y, sobre todo, para conectarse a Internet a alta velocidad desde el celular.
Mientras los argentinos comprobamos en carne propia este atraso todos los días, ya hay 18 países en América del Sur y el Caribe que lanzaron servicios 4G LTE, mientras que en Europa y los Estados Unidos ya se experimentan versiones más avanzadas aún.
Esta realidad tampoco es desconocida para el Gobierno, que, sin embargo, con las medidas adoptadas un año atrás, lo único que logró fue justamente atrasar a todo el sector local de la telefonía móvil. Como se recordará, en febrero de 2013, se decidió dejar sin efecto una licitación pública para asignar frecuencias radioeléctricas para los servicios de telefonía móvil, y la Presidenta instruyó al secretario de Comunicaciones, Norberto Berner, para que asignara esas frecuencias a la Empresa Argentina de Soluciones Satelitales SA (AR-SAT), propiedad del Estado, cosa que hasta ahora no ha ocurrido. Ya en diciembre de 2012, la mandataria y el ministro de Planificación, Julio De Vido, habían anunciado también la creación de Libre.ar, una nueva marca de servicios de telefonía móvil que prestaría el Estado a través de AR-SAT -fue presentada como una acción para "recuperar el éter para los argentinos"-, pero ésta fue la última noticia importante que se tuvo de esta operadora móvil.
Por su parte, las tres principales operadoras móviles de la Argentina -Telefónica, Telecom y Claro- siguen esperando que el Gobierno haga algún anuncio al respecto, y tratan de capear las cada día más crecientes dificultades para evitar las caídas recurrentes de sus redes; la demanda de ancho de banda por medio del móvil -con dispositivos cada vez más potentes- no deja de crecer, y exige mayores ajustes en las redes, con nuevas antenas y radiobases. Con este panorama, en el que las autoridades nacionales parecen no darse cuenta de la importancia del tema, no resulta extraño que la única funcionaria argentina presente en el MWC haya sido la gerenta de control de la Comisión Nacional de Comunicaciones, Anabel Cisneros.
Decíamos que la Argentina está lejos incluso de lo que es el enorme negocio digital: si licitara espectro -un recurso natural limitado por el que se transmiten las señales inalámbricas- para 4G, podría recaudar por lo menos 1000 millones de dólares, y otros 1500 millones serían necesarios para que las tres operadoras móviles locales comiencen a desplegar redes 4G LTE.
Hoy, además de la indefinición política, se cierne otro inconveniente grave: se confirmó que el servicio móvil LTE puede interferir la televisión digital terrestre, que tiene en la Argentina el país con mayor alcance de América latina. No hay que olvidar otras dos cuestiones que también dificultarían la llegada al país de la nueva tecnología: la exigencia de ensamblado de los teléfonos en Tierra del Fuego, que termina encareciendo sus precios, y el freno aduanero a las importaciones de antenas y equipos para evitar la salida de dólares.
Si pensamos que la última licitación de espectro se realizó en 1999, cuando había poco más de dos millones de usuarios de telefonía celular, y que ahora, con mucho más de cincuenta millones de líneas móviles en servicio y con dispositivos que, al permitir el acceso a Internet y a contenidos de multimedia requieren muchas más frecuencias, se está operando en las mismas condiciones que hace 13 años, se comprenderá la gravedad de la situación actual.

jueves, febrero 20, 2014

Tropezando en software mal terminado

Alguna vez, James Bach decía que hoy no tenía sentido el testeo del software, porque no existía uno que se entregara con una revisión cuidada. Mejor en sus palabras, allá por marzo de 2009:
My impression is that up to about ten years ago most companies were still trying, in good faith, to put out a good product. But now many of them, especially the biggest ones, have completely given up. One sign of this is the outsourcing trend. Offshore companies, almost universally, are unwilling and unable to provide solid evidence of their expertise. But that doesn’t matter, because the managers offering them the work care for nothing but the hourly rate of the testers. The ability of the testers to test means nothing. In fact, bright inquisitive testers seem to be frowned upon as troublemakers.
(...) This is my Quality is Dead hypothesis: a pleasing level of quality for end users has become too hard to achieve while demand for it has simultaneously evaporated and penalties for not achieving it are weak. The entropy caused by mindboggling change and innovation in computing has reached a point where it is extremely expensive to use traditional development and testing methods to create reasonably good products and get a reasonable return on investment. Meanwhile, user expectations of quality have been beaten out of them. When I say quality is dead, I don’t mean that it’s dying, or that it’s under threat. What I mean is that we have collectively– and rationally– ceased to expect that software normally works well, even under normal conditions. Furthermore, there is very little any one user can do about it.
Esta incómoda afirmación de un especialista, se puede comprobar a diario, a cualquier nivel. Un incidente esta semana pasada me lo hizo recordar: migraba en Eclipse la versión de una librería que uso, a su último fix (esto sólo ya daría para hablar largo sobre políticas de entrega de producto). Ésto, mientras a la vez migraba de sistema operativo y máquina: demasiados frentes abiertos; Windows 7 a su último nivel crítico de actualizaciones, Visual Studio y Java instalados por primera vez en la máquina; en este último caso, a las instalaciones de JRE de Java 6 y Java 7, agregamos la instalación del JDK de JEE 6, tomando la última versión ofrecida por Oracle en su sitio de descargas para JEE 6: la que se instala con Java SE modificación 29.
Haciendo las primeras pruebas de funcionamiento de Eclipse con el proyecto en que trabajaba, encontré que la primera aplicación que probaba fallaba a poco de iniciarse. Después de algo de búsqueda, el problema quedó localizado en la primera llamada a Microsoft SQL Server, con la particularidad de que la llamada al driver sqljdbc4.jar recibía el control, y comenzaba la descarga de clases necesarias, hasta detenerse en una llamada en particular, sin provocar una excepción: simplemente la aplicación se colgaba sin aviso de ningún tipo, ni siquiera en el visor de eventos de Windows. La primera acción fue comparar la carga de clases en las dos máquinas involucaradas (la que estaba migrando, y la de destino, nueva), y tratar de asegurar que no se estuviera solicitando una clase que faltara en el jar cargado. Una búsqueda en todas las carpetas encontró no menos de seis copias del jar, pero ninguno de ellos podría haber entrado en conflicto, y la copia que debiera llamarse estaba en la ruta esperada. A pesar de que hubo que hacer algo de limpieza del número de copias y de sus rutas, este no era el problema. Por lo tanto, decidí comenzar una búsqueda de incidencias entre Java,  JEE, servlets, Microsoft SQL Server jdbc, y/o SQL en general. A poco de revisar, apareció una consulta en StackOverflow, que vinculaba la incidencia a la modificación 29 de Java SE. Siguiendo su discusión, llegué al caso en Oracle: JDK-7103725 : REGRESSION - 6u29 breaks ssl connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA. En la evaluación del impacto del fallo, se afirma: "The more obvious impact of this bug is to the MS JDBC Driver and MS SQL Server".
Tanto los comentarios en StackOverflow como la propia descripción del problema corregido coincidían en sus efectos con el que nos afectaba. De modo que, siguiendo las líneas recomendadas allí,  descargamos una versión posterior de Java SE,  la última disponible para Java 6, la modificación 45. Reemplazada la versión, no hubo más que arrancar Eclipse y la aplicación para encontrar todo trabajando normalmente...
Ahora, atemos nuestro percance con lo que James Bach dice más arriba: cuando instalábamos esta máquina, buscamos el paquete de JEE 6 en su sitio oficial, donde JEE 6 con el sdk de Java SE m29 es una de las opciones disponibles. Si bien la elección entre varias opciones fue nuestra, no existía ninguna advertencia de dificultades con JDBC (!) o SQL Server ni su documentación advierte que existe un problema, y que para resolverlo...se debe cambiar de versión. ¿Qué clase de entrega de un producto es una que no dice que fallará bajo ciertas circunstancias, para más, bastante comunes, cuando eso ya fue detectado? ¿Qué protocolo de comunicación existe entre quienes desarrollan el producto (JEE) y quienes lo mantienen (Java Community)?
Este es sólo un minúsculo ejemplo; sólo en el proceso de resolver este inconveniente podría hablar de varias imperfecciones de todo tipo, tan simples como insólitos resultados de la búsqueda de un objeto en el sistema de archivos (fallo en Windows 7), o la imposibilidad de usar las herramientas de desarrollador en Internet Explorer. O encontrar que un fix produce otro fallo que requiere otro fix al día siguiente...y otro más un día después.
En una época en que los métodos ágiles predominan, conjeturo que algo de responsabilidad les corresponde: reducir los tiempos de entrega, simplificar las metas de cada release, creo que también conducen a este estado de permanente falta de terminación.

jueves, enero 09, 2014

Crónica de una desaparición

Buscando documentación de Plex en el repositorio de documentos del soporte de CA, encontré una entrada para un producto que me resultaba familiar: CA NetViz. Por curiosidad, entré a su página y descargué uno de los materiales disponibles, el Quick Start Guide. De la lectura no se podía extraer mucho, porque el texto se enfocaba muy específicamente en los pasos de instalación. De modo que opté por buscar en Internet algo más de información, lo que actualizó suficientemente el panorama...

En primer lugar, en efecto, CA NetViz era el "viejo" producto que conocí más o menos para el año 2000: un diagramador o visualizador de redes, con un conjunto de sentencias para crear los elementos de una red, de tal modo que una red se podía describir con un conjunto de fórmulas y referencias; las referencias representando nodos y enlaces que podían mantenerse en una base de datos. Era posible crear y mantener (agregar y quitar) la red a través de su definición matricial, y explotarla cuando fuera necesario. Los nodos podían asociar información (nuevas tablas) y representaciones visuales; los conjuntos o subconjuntos de redes podían desplegarse sobre mapas o planos sensibles a la definición de nodos y enlaces. En fin, se podían expresar todo tipo de datos representables como redes (redes informáticas, telefónicas, logísticas, y lo que se imagine); entonces me pareció un producto potente, muy útil en su contexto. Y dado que tenía un lenguaje de scripting que permitía la manipulación de sus elementos (crear enlaces, nodos, planos, asociar imágenes a nodos y enlaces, agregar ítems de información a cada elemento, etc), por un tiempo le dí vueltas a la posibilidad de asociar una aplicación creada con Plex (por ejemplo), que invocara estos scripts de acuerdo a necesidad, y que disparara su representación visual cuando correspondiera. Sin embargo, en el interín, antes de conversarlo con nadie, me enteré que la pequeña empresa creadora de NetViz, cuyo principal negocio era éste, había sido comprada por otra mayor, Concord Communications, cuyo negocio era el monitoreo de performance de sistemas de comunicación: para esta empresa la herramienta estaba orientada a un propósito definido, y el hecho de que fuera su nuevo propietario me hizo dejar de lado cualquier plan sobre sus posibilidades ¿qué horizonte podría tener esta aplicación bajo estas nuevas circunstancias?

Pues bien, de la breve búsqueda en Internet, encontré que Concord Communications también había sido comprada en 2005, ahora por Computer Associates (hoy CA). Entonces, el propósito de CA era entrar con fuerza en el negocio de redes ("From CA's point of view, this will strengthen their network management to better compete against HP", comentaba CNET). En la negociación, NetViz era una parte menor del portafolio.Deduzco, por su situación actual en el catálogo, que se le buscó un nicho propio de mercado, al margen de lo que Concord representara, y se delegó a antiguos distribuidores la tarea de hacer clientes. Consecuencia, en 2011 CA anunció el "end of life", lo que significa que NetViz no sería ya mejorada ni soportada a partir de 2012: This means CA netViz will no longer be enhanced and that maintenance and technical support will be discontinued beginning June 30, 2012. However, CA Technologies will honor any existing contractual requirements to sustain support on this product that may exist between you and CA Technologies.
No obstante, NetViz continúa siendo propiedad de CA, como se desprende de algunos comentarios, y del hecho de que NetViz sigue listado en CA.

Así, un producto interesante, útil seguramente para un buen segmento de mercado, fue arrastrado y engullido por una sucesión de decisiones de negocios donde jugó el papel de un peón de ajedrez. Las leyes de Darwin en pleno funcionamiento. Hay un elemento común a la mayor parte de las compras de un producto interesante: que éste se convierte en tal porque un núcleo de personas tiene una visión, la pone en práctica, y trabaja con pasión por su crecimiento. El día que por las buenas o por las malas este producto pasa a un nuevo dueño, éste ve su valor comercial, su potencialidad de negocios, pero no tiene el entusiasmo para sostenerlo; al cabo de un tiempo, nuevos funcionarios a cargo no logran sostenerlo, y el dueño del negocio se impacienta por los rendimientos. Y así siguiendo...
¿Cuántos casos como éste conocemos? Sin pensar, puedo recordar a Essbase, Brio, porque los ví directamente, pero sin duda podemos hacer una lista de cientos sólo pensando un rato.

lunes, enero 06, 2014

Conferencia anual de Plex, 12 de noviembre de 2013

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

miércoles, enero 01, 2014

Comenzando 2014...

Para comenzar 2014, una declaración de posibilidades no vendría mal... especialmente si el último comentario aquí tiene cinco meses. Existen varias razones por las que no se han agregado notas en tanto tiempo, y probablemente una de las más importantes es que este ha sido un tiempo dedicado a trabajar pegado a java: mucho tiempo consumido investigando librerías, creando APIs, testeando respuesta. Mucho tiempo repartido entre Tomcat y Websphere, analizando problemas mientras implementamos un par de aplicaciones. Otras dos razones están relacionadas con las novedades (o para decir mejor, el estado) de Plex, y con la evolución actual de MDD: en el primer caso, las novedades nacidas de la versión 7.0 están fuera de mi alcance, ya que se orientan al soporte de WCF y .NET, áreas que hoy están fuera de mi foco (ya he dicho que estoy concentrado con Java -y JEE), con lo que poco estoy en condiciones de agregar. Y en cuanto a MDD, no encuentro en estos meses novedades relevantes que agregar.
En fin, mi declaración de posibilidades va a lo siguiente: hay muchos asuntos de interés en Plex que trataré de conversar, aunque esto restrinja un poco el foco de los temas. De eso trataremos especialmente este año. Otros asuntos los tomaremos en base a lo que el tiempo disponible permita.
Esto mismo vale para mi página sobre estos temas, que reformaré por segunda vez, simplificando el contenido, recortando las listas de enlaces, que nunca han servido demasiado por su inestabilidad: no estoy en condiciones de rever todos los trimestres quién cambió o eliminó un tema de interes que fue enlazado anteriormente. Y otras cosas que quisiera tratar de otra manera.
Esto es todo por ahora, y espero que el siguiente comentario no sea un felíz 2015...

domingo, julio 28, 2013

DSLs en su lugar

Una "vieja" entrada del blog de Bertrand Meyer, necesaria de recordar cuando se habla de DSLs (Domain Specific Languages) con alguna liberalidad: en ocasiones se los propone para resolver problemas específicos  que parecen condenados a bufurcar el camino de trabajo. La posición de Meyer es radical: ¿cuándo crear un lenguaje de dominio? Nunca:
El contexto:
It is a common occurrence in software development. Someone says: “We should design a language”. The usual context is that some part of the development requires a rich functionality set, and it appears appropriate to provide a flexible solution through a specialized language.
La objeción de Meyer:
Designing a language in such a context is almost always a bad idea (and I am not sure why I wrote “almost”). Languages are endless objects of discussion, usually on the least important aspects, which are also the most visible and those on which everyone has a strong opinion: concrete syntactic properties. People might pretend otherwise (“let’s not get bogged down on syntax, this is just one possible form”) but syntax is what the discussions will get bogged down to — keywords or symbols, this order or that order of operands, one instruction with several variants vs. several instructions… — at the expense of discussing the fundamental issues of functionality.
Worse yet, even if a language will be part of the solution it is usually just one facet to the solution.As was already explained in detail in [1], any useful functionality set will naturally be useful through several interfaces: a textual notation with concrete syntax may be one of them, but other possible ones include an API (Abstract Program Interface) for use from other software elements, a Graphical User Interface, a web user interface, yet another for web services (typically WSDL or some other XML or JSON format).
In such cases, starting with a concrete textual language is pretty silly, since it cannot yield the others directly (it would have to be parsed and further analyzed, which does not make sense). Of all the kinds of interface listed, the most fundamental one is the API: it describes the raw functionality, excluding any choice of syntax but including, thanks to contracts, elements of semantics.
Conclusión:
One of the key rules for successful software construction — as for many other ventures of course, especially in science and technology — is to distinguish the essential from the auxiliary, and consequently to devote proper attention to the essential issues while avoiding disputations of auxiliary issues. To define functionality, API is essential; language is auxiliary.
So when should you design a language? Never. Well, hardly ever.
 Si computaramos el tiempo de trabajo para definir el DSL y asegurar que funcione, en tales contextos, la adhesión a la posición de Meyer es segura...

jueves, julio 18, 2013

Cloud computing y soberanía

La reciente comprobación de la nula privacidad de las comunicaciones electrónicas, ya no sólo en el tráfico de datos, sino también en las comunicaciones telefónicas o incluso en el seguimiento de matrículas de autos, ha establecido un freno importante a la expectativa de uso de cloud computing. No estamos hablando ahora sólo de prevenciones en cuanto a la seguridad o disponibilidad de los datos y servicios, sino de la intromisión incontrolada en su contenido. La comprobación de que distintas oficinas de control de seguridad en múltiples países pueden acceder a datos privados sin mediar una orden judicial expresa, pone en duda cualquier plan de externalización de datos. ¿Pueden sus datos, bajo circunstancias especiales, estar sujetos a espionaje industrial?. Quizá sea hora de pensar dos o tres veces qué se pondrá fuera del control de una red privada.
Pablo Albarracín, en América Economía, puntualiza los problemas jurídicos relacionados con la normativa que cada país dicte para la protección de datos, destacando que estos se convierten en un problema de soberanía nacional:
El caso PRISM ha resucitado la preocupación sobre la soberanía de los datos. ¿Los datos que una compañía o gobierno considera estratégicos, deben estar en una nube internacional o en servidores y data centers dentro del territorio nacional? La masiva adopción del cloud, desde el popular Gmail a sofisticadas plataformas empresariales, está provocando una ambigüedad geopolítica de datos en todos los frentes. Dicho de otro modo, Snowden sacudió en la cara de todos los gobiernos y agencias de seguridad del mundo su deficiente soberanía informática.
El tema es más importante de lo que aparenta, puesto que pone en juego la reputación y confiabilidad del cloud como depositorio de los datos críticos, como pueden ser secretos militares, patentes industriales, información de los clientes de un banco o la información clínica de toda una ciudad o región. Una óptima adopción del cloud debería asegurar que los proveedores de la nube garanticen a sus clientes que los datos se alojen en el país de origen."La soberanía de datos se ha convertido en la principal preocupación para los clientes fuera de los EE.UU. que están buscando la adopción de una nube pública", dice el informe de Gartner Data Sovereignty Can Be a Hurdle for the Adoption of Cloud Computing. "Durante los próximos cinco años, los problemas de soberanía de datos disminuirán a medida que más proveedores pongan atención a este asunto. Sin embargo, el problema no va a desaparecer por completo".

De esta manera, tanto el cliente como el proveedor de la tecnología, evitan confusiones relativas a las diferentes normativas legales que cada país posee y que pueden generar problemas al momento de enfrentar un litigio (Google y Microsoft mucho saben de esto a raíz de PRISM). Más aún, cuando la oferta cloud está abarcando no sólo la capa de software (SaaS), sino que los niveles más físicos del cloud también cuentan con una oferta deslocalizada (IaaS, PaaS). La seguridad nacional puede estar en riesgo.
“Los datos no son de Google, los datos son de las empresas. Ellas son las dueñas de los datos y se responsabilizan de la información"
, dice Gabriela Franchetto, Google Enterprise Sales Manager. "Google se pone a disposición de ustedes (los clientes), pero los datos no son nuestros, sólo la infraestructura que los aloja”. (Conozca más sobre los aspectos legales y técnicos en la adopción del cloud en el reportaje: Leyes del Cloud Computing: ¿está la región preparada para subirse a la nube?)

Según el estudio Data Sovereignty and the Cloud de la University of New South Wales (UNSW) y el Cyberspace Law and Policy Centre, el lugar donde se alojan los datos es una problemática no sólo técnica, sino que legal y estratégica de un país. El tema ha dejado de ser asunto exclusivo de abogados a considerarse un punto importantísimo en gestión de riesgo, empresarial como gubernamental, situación que irá creciendo con los años.
Albarracín destaca la probable acción de Brasil expresada a través de su ministro de Comunicaciones, Paulo Bernardo Silva, de exigir por ley a sus proveedores de servicio de almacenamiento de datos de que éstos sean alojados en el país:
Según informó EFE, el ministro afirmó que el almacenamiento de los datos en el país es un asunto de soberanía nacional debido a que las empresas de internet se están negando a ofrecerle datos a la justicia brasileña con la disculpa de que sus archivos no están en el país. Bernardo se refirió a la reciente negativa de Google de entregar copias de un e-mail a un tribunal que investiga un caso de lavado de dinero. "Con esas denuncias (de Snowden) vimos que ellos (las empresas) entregan todo. Aquí alegan que no pueden hacerlo".
"Creamos incentivos para que los centros de datos se instalasen en Brasil y les suspendimos todos los impuestos sobre la compra de equipos, pero creo que ahora vamos a tener que obligarlos a almacenar los datos aquí". Bernardo señaló que además de obligar a las empresas a archivar sus datos en el país, el gobierno también va a invertir en infraestructura de  redes locales y a promover una reforma en la gestión internacional de internet, para que sea asumida por la ONU y no por Estados Unidos.

"El problema es que la internet tiene reglas de gestión exclusivamente dictadas por Estados Unidos.
Defendemos una gestión multilateral y multisectorial. Países y sociedades tienen que estar representados, pero los Estados Unidos se resisten mucho y frenan cualquier intento de discusión sobre el asunto", puntualizó.
La probable exigencia de Brasil de radicar localmente los datos, de todas formas, no hace sino agregar una razón más a las dudas más que razonables de externalizar datos: localizarlos fronteras adentro no cambia el problema, sólo lo sujeta a las particulares exigencias de las agencias nacionales. Es decir: quien piense en externalizar, piense de nuevo. Y no sólo con un abogado, sino con un analista político.

domingo, julio 07, 2013

Comienza el beta test para Plex 7.1

Simon Cockayne, Product Manager para Plex y 2E desde mayo último, anunció en estos días la convocatoria a clientes registrados para participar del test beta de Plex 7.1. Una buena parte de las mejoras programadas de incluír en la nueva versión están orientadas al soporte de .NET, WCF y Azure, y Kerberos en IBM i (AKA iSeries, ex AS400). De interés por lo tanto para todos aquellos clientes que utilicen estas variantes. Está programada también una nueva facilidad interna de la IDE: la creación de perfiles de configuración que puedan ser invocados de una lista. Esta es una solicitud de la comunidad que lleva tiempo en espera, que facilitará a todos el uso de variantes y versiones, libres de errores de configuración manual.
A la larga práctica de convocar a clientes y desarrolladores a los beta test de Plex y 2E, CA ha agregado el uso de técnicas ágiles de evolución y prueba del producto, que prometen ciclos más cortos de cambio. Otra parte clave de esta filosofía, es la inclusión del repositorio de ideas en la Comunidad Global de Plex/2e (y otros productos), en la que es posible postular mejoras y correcciones, con la habilidad de votarlas y ranquearlas.  Estas son tomadas en cuenta para la elaborar la evolución del producto.
Por lo tanto, están invitados a participar y adelantar los cambios propuestos...

RPG antes y ahora

Este año se cumplieron veinticinco años de la aparición del As400/iSeries/System i o cualquier otro nombre que se propongan agregarle. De su robustez y excelente diseño dan testimonio dos artículos recientes: uno dedicado a recordar sus primeros ensayos y nacimiento, y otro evaluando el estado actual del RPG como lenguaje moderno. El primero, escrito por Mel Beckman, recuerda su inicio como programador, participando en beta tests del equipo en una empresa cercana a Rochester. Sólo rescato dos párrafos:
Despite the plethora of early bugs, we RPG programmers quickly began to see their frequency decreasing as the S/38 OS, called CPF (Control Program Facility) stabilized. S/38’s single-level store, object-oriented architecture, and integrated database really did seem to make programs more reliable, heading off the most common coding gaffs and preventing wholesale machine crashes. As the S/38 matured, it gained a reputation for solid reliability in the finance and healthcare industries, which are still strong markets for the system’s descendent, today’s IBM i. Throughout the S/38’s evolution to AS/400, iSeries, and ultimately Power hardware architectures, IBM has been able to preserve customer’s investment in business logic and data storage.
I had no idea then just how powerful the S/38’s innovations would turn out to be. They enabled IBM, and its many customers, to transport an immense amount of binary code and data into the future – not just twenty-five years, but thirty years, with very few disruptions. IBM promised, with both the S/38 and the IBM i, to protect users’ business investment in applications, processes, and logic.
In the intervening decades, many other systems have come and gone, dragging their user populations into oblivion with them. Only IBM i has preserved a continuous architectural path that is still going strong today. In 2013 it’s clear that IBM alone kept it’s promise.
El segundo artículo es un editorial del IBM System Magazine, escrito a propósito de las celebraciones de los 25 años del equipo (sistema operativo + recursos + hardware), puntualiza el estado actual del RPG, que de ninguna manera es ya lo que inicialmente fue (generador de reportes):
In reading today’s anniversary chapter, Susan learned something new—although Jon claims he knew it long ago. When RPG IV was introduced, the name “RPG” was officially declared to be no longer an acronym—or, more correctly as Scott Klement pointed out recently, an initialism. For those who didn’t realize this, to be an acronym, apparently it must be pronounceable as a word, such as NATO. If it is simply spelt out, as RPG is, it’s technically an initialism.
While the letters RPG may not officially stand for anything any more, RPG, the language, means a great deal to many thousands of programmers around the world and the users of their rock-solid, efficient, modern business applications.
In many ways it’s a good thing that RPG no longer stands for “Report Program Generator” because it has been many, many years since RPG’s primary function was reporting. It has evolved radically over the years.
If the picture that comes to your mind when you think of RPG is of columnar logic with multiple conditioning indicators and nary a hint of SQL, it’s time to wake up, Sleeping Beauty—you’ve missed a lot in the last 25 years. IBM i’s modern RPG IV is barely recognizable as a relative of the AS/400’s original RPG/400.
Today’s RPG logic is written in free format. It also utilizes libraries of homegrown, open-source and third-party functions in addition to RPG’s own library of more than 70 BIFs (built-in-functions). As a result, what would have been dozens of lines of indicator-laden, columnar “old-style” RPG are replaced by simple, powerful expressions.  And RPG’s data access has “grown up” too. Support for a huge variety of native data types and a deeper level of integration with SQL than is seen in almost any other language makes RPG a natural partner for IBM i’s integrated DB2 database.
Still think that RPG = Green Screen? Think again. Many shops are running interactive Web and mobile applications with logic powered by RPG. Or if you prefer, RPG code can easily provide the business logic underpinnings of Web services, stored procedures and other services to applications written in PHP, Java, Python, Ruby, .NET, etc.
Inevitably there are things that RPG doesn’t understand natively and that IBM cannot add to the language in a meaningful timeframe. The pace of change in today’s IT world is just too fast. That’s why Open Access was recently added to the language. It allows for the development of drivers to add new functionality while maintaining RPG’s powerful data marshaling capabilities. For example, you can write a driver to call a currency conversion Web service from RPG, allowing any RPG program to treat access to real-time currency conversion data as if it were a huge database in the sky. Simply set the key values for the currencies involved and issue a CHAIN operation. The conversion rate is returned as if it were being retrieved from a database column.
Como los autores dicen, mientras hemos visto pasar y desaparece equipos, lenguajes y arquitecturas, el diseño conceptual del AS400 sigue vigente y en primera línea. Centenares de miles de instalaciones lo demuestran. Quizá aún a pesar de algún directivo de la propia IBM, que a veces parece dudar de su producto.

miércoles, junio 19, 2013

Privacidad de datos y Cloud Computing

del último número de Dr Dobb's, comentario de un usuario:
 From the beginning, I have always questioned the pros and cons of the cloud and their services. I have my doubts concerning security, privacy, corporate fortitude, and price and rule changes of cloud providers. Your discussions have moved me further away from these services and have added extra nails to their coffin.
— JLONERO8255, Dr. Dobb's member
Expresado en las respuestas y comentarios al artículo Through a PRISM darkly.

Del propio artículo:
The first and most profound effect will be a serious reconsideration of the wisdom of putting data into the public cloud. The previous argument for migrating data and apps to the cloud was that cloud hosts, such as Amazon, Google, and Microsoft, are much better at defending their systems from hackers than most corporate IT departments are. This view is supported by the contention that those companies can afford to hire hundreds of security professionals to provide the necessary protection, vigilance, and intelligent response — while most IT organizations can hire perhaps a few dozen, with no real ability to scale response in times of attack.
This argument, taken by itself, is still valid. However, it can no longer be taken by itself. A new dimension has appeared; namely, that the government can more or less at will see the contents of communications and data held on servers at cloud hosts. The important factor is that the government can gain this access without ever notifying the target company that its data has been copied to government servers.
Cada uno que ajuste sus propias cargas...

sábado, mayo 25, 2013

UML en la ICSE 2013

Anteúltimo día de ICSE 2013 (International Conference on Software Engineering) , que muestra un gran número de trabajos de interés y participantes. A esta hora, destaco el que Timothy Lethbridge comenta, aunque por razones diversas: la presentación de Marian Petre "UML in practice", que resume su investigación sobre una muestra de desarrolladores de software, respecto a su uso o no de UML. En el resúmen de Timothy
She conducted an excellent interview-based study of 50 software developers in a wide variety of industries and geographical locations. Her key question was, "Do you use UML".

She found that only 15 out of 50 use it in some way, and none use it wholeheartedly.

A total of 11 use it selectively, adapting it as necessary depending on the audience. Of this group use of diagram types was: Class diagrams: 7, sequence diagrams: 6, activity diagrams: 6, state diagrams: 2 and use case diagrams: 1.

Only 3 used it for code generation; these were generally in the context of product lines and embedded software. Such users, however, tended not to use it for early phases of design, only for generation.

One used it in what she called 'retrofit' mode, i.e. "Not unless the client demands it for some reason".

That leaves the 35 software developers who do not use it (70%). Some reported historical use, and some of these did in fact model using their own notation.

The main complaints were that it is unnecessarily complex, lacks and ability to represent the whole system, and has difficulties when it comes to synchronization of artifacts. There were also comments about certain diagram types, such as state machines being only used as an aid to thinking. In general, diagram types were seen as not working well together.

She did comment on the fact that UML is widely taught in educational programs.
Como Tijs van der Storm comenta, quizá Marian esté martillando los últimos clavos en el ataúd de UML...
También coinciden en sus comentarios James NobleAlex Nederlof, y Leif Singer, entre otros. Éste último apunta al uso de UML en educación registrado por Marian, como muchas veces, y en muchos aspectos, corriendo detrás de la situación real.