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.

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

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.

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.

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.

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.

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.

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

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

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.

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.

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

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 Noble,  Alex 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.

Android, nueva IDE?

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

Wikipedia y la programación

Parece ser que, en Wikipedia, no hemos logrado el respaldo de los mejores escritores en algunas áreas de programación. En OOP, desde el mismo concepto hasta varios de sus elementos constitutivos, aparecen débilmente definidos: encapsulamiento, herencia, polimorfismo, interfaz, y varios otros. Quizá se podría decir que más interesante que el artículo en sí, es, en cada caso, la discusión entre los redactores y observadores. Creo que sería más conveniente la creación de un grupo de trabajo con respaldo en buenos conocimientos, que discutiera un enfoque general común, y mantuviera un plan de redacción unificado y consistente, que abarque el problema con mejor sustento teórico, y un plan homogéneo de casos y ejemplos. No parece recomendable en varios casos, acudir a Wikipedia en busca de una respuesta. En este caso, es preferible la versión inglesa.

Treinta años de Internet

Ariel Torres, en La Nación, comenta y rememora la creación de los protocolos que dieron lugar a Internet, hace treinta años, es decir, en enero de 1983. Coincidiendo con el inicio de la época en que el eje se desplazaba de mainframes o equipos de rango medio a las PCs, donde todavía reinaba IBM. Recuerdo las discusiones en revistas técnicas de networking, donde todavía ARPANET era el centro de la actividad: las nuevas perspectivas aparecían muy prometedoras desde su mismo inicio. Y aún faltaba para la WWW, y tampoco se hablaba todavía de la "autopista de la información". Habla Ariel Torres:

Fue un enero como cualquier otro, con noticias de primera plana, como la erupción del volcán Kilauea (cuya lava todavía hoy continúa fluyendo), el retiro de tenista Björn Borg de las canchas, el arresto del criminal nazi Klaus Barbie en Bolivia y la sentencia a cadena perpetua de 25 miembros de las Brigadas Rojas, en Italia, por el asesinato de Aldo Moro. Hubo también noticias menos relevantes, relacionadas con unas máquinas que se venían vendiendo como pan caliente desde agosto de 1981, las IBM/PC. En efecto, en enero de 1983 salía la primera versión de la planilla de cálculo Lotus 1-2-3 , que pronto se transformaría en una herramienta ineludible de la informática personal.
Detrás de estas noticias grandes y pequeñas, locales e internacionales, ocurrió algo sobre lo que no hubo crónica ni titular, pero que transformaría nuestra realidad, en los siguientes 30 años, más allá de lo que nadie por entonces se atrevía a imaginar. El primer día de 1983 nació Internet. O, dicho de otra forma, se completó la migración de los protocolos usados en Arpanet (los NCP, por Network Control Program) a los protocolos de Internet, los hoy bien conocidos y universalmente usados TCP/IP.
Arpanet, que había sido puesta en marcha el 29 de octubre de 1969 a las 10 y media de la noche , y que es considerada la antecesora de Internet, había comenzado a mostrar sus limitaciones en los primeros años de la década del '70. En 1973 se puso sobre la mesa la idea de que se necesitaba renovar la tecnología de tal modo que la transmisión de paquetes de datos pudiera realizarse no ya entre hosts (computadoras, por así decir), sino entre redes de computadoras. De hecho, la palabra Internet proviene de ese concepto, el de internetting , conectar redes entre sí, lo mismo que la frase red de redes para referirse a Internet.

Vinton Cerf, Lawrence Roberts (promotor de Arpanet), Bob Kahn y Tim Berners-Lee (creador de la Web) en 2002, cuando recibieron el Príncipe de Asturias. (Foto y leyenda de La Nación)

Vinton Cerf y Bob Kahn fueron los responsables de crear el nuevo conjunto de protocolos, es decir, la nueva tecnología de conexión a la que hoy llamamos, simplemente, Internet. Empezaron a trabajar en el proyecto en el verano de 1973, bosquejando las ideas básicas, que durante los siguientes 4 años se formularían, codificarían y consolidarían. En noviembre de 1977 se hizo el primer experimento conectando tres redes mediante TCP/IP, una en Noruega, otra en Inglaterra y la tercera en los Estados Unidos.
En total, les llevó 10 años y un ejército de programadores el crear, implementar y migrar a los TCP/IP; esto es, poner en marcha Internet. Pero cumplieron a rajatabla con el plan que se habían impuesto y el primer día de enero de 1983, aunque no salió en los diarios ni se le dedicó un instante de TV, este esforzado equipo de hombres y mujeres plantó los cimientos de una tecnología que cambiaría el mundo para siempre.
La falta de cobertura no fue, sin embargo, una falla de los periodistas. Por entonces, la recién nacida Internet era un experimento académico, tan lejos del resto de nosotros como los viajes espaciales, y ciertamente mucho menos atractivo. Una cosa de científicos. Habrían de pasar otros 7 años antes de que el público pudiera conectarse a la red de redes en los Estados Unidos. En la Argentina, que había sido conectada a Internet en 1990, los accesos a particulares llegarían en 1995. Es decir, 12 años después del nacimiento de la Red. Puede leerse (en inglés) el plan de migración de NCP a TCP/IP en este histórico documento .

 En Wikipedia en español hay una historia que debe complementarse con su versión inglesa. En la versión en castellano hay un cuadro de ARPANET que muestra el estado previo de las redes públicas.
Sólo mencionado al pasar: observo que el concepto "autopista de la información" están explicados de manera muy diferente en inglés o en castellano. Mucho que hablar sobre la preparación de artículos para Wikipedia...

Java legacy, II

A propósito de las afirmaciones sobre la declinación de Java, mayores hacia inicios de año que ahora, Martijn Verburg, en su revista de Java para 2012, se refiere al tema y lo refuta claramente:

The community continues to thrive despite many main stream tech media reports of ‘developers leaving the Java platform’ or ‘Java is dead’. There are more Java User Groups (JUGs) than ever before, consisting of ~400,000 developers world wide.
Notably, one of them, the London Java Community won several awards including the Duke’s Choice award and JCP Member of the Year (along with SouJava – the major Brazilian JUG).
The conference circuit is bursting at the seams with large, sold out in advance, world-class Java conferences such as JFokus, Devoxx and of course JavaOne. In addition to this the host of regional conferences that often pack in an audience of over 1000 people all continued to do well.
Oracle’s Java Magazine was launched and has grown to over 100,000 subscribers. Stalwarts like JaxEnter, Coderanch and the Javaposse continue to grow in audience sizes.

OpenJDK

Further OpenJDK reforms happened over 2012 and a new scorecard is now in place for the wider community to give feedback on governance, openness and transparency.
2012 also saw a record number of individuals and organisations joining OpenJDK. In particular, the port to the ARM processor and support for running Java on graphic cards (Project Sumatra) were highlights this year.

Java Community Process (JCP)

The Java Community Process (JCP), Java’s standards body also continued its revival with record numbers of new sign-ups and a hotly contested election. As well as dealing with the important business of trademarks, IP and licensing for Java, a re-focus on the technical aspects for Java Specification Requests (JSRs) occurred. In particular the new Adopt a JSR programme is being strongly supported by the JCP.

Java and the JVM

The JVM continues to improve rapidly through OpenJDK – the number of Java Enhancement Proposals (JEPs) going into Java 8 is enormous. Jigsaw dropping out was a disappointing but given the lack of broader vendor support and the vast amount of technical work required, it was the correct decision.

JEE / Spring

JEE7 is moving along nicely (and will be out soon), bringing Java developers a standard way to deal with the modern web (JSON, Web Sockets, etc). Of course many developers are already using the SpringSource suite of APIs but it’s good to see advancement in the underlying specs.

Rapid Web Development

Java/JVM based rapid web development frameworks are finally gaining the recognition they deserve. Frameworks like JBoss’s SEAM, Spring Roo, Grails, Play etc all give Java developers parity with the Rails and Django crowd.

Mechanical Sympathy

A major focus of 2012 was on Mechanical Sympathy (as coined by Martin Thompson in his blog). The tide has turned, and we now have to contend with having multi-core machines and virtualised O/S’s. Java developers have had to start thinking about how Java and the JVM interacts with the underlying platform and hardware.
Performance companies like jClarity are building tooling to help developers understand this complex space, but it certainly doesn’t hurt to get those hardware manuals off the shelf again!

Y cuando Martijn se refiere a las perspectivas de 2013, la expectativa persiste, con Java 8 en deliberación. Pero mejor vea el artículo, o siga Java Code Geeks. Al menos en mi caso, encuentro usualmente excelente material práctico con ellos.

¿Java Legacy?

Esta es una noticia "vieja": InfoQ comenta la migración de Twitter de Ruby a Java a propósito de la exitosa travesía de Twitter durante las elecciones estadounidenses. Twitter resistió 327.452 tweets por minuto, hasta 15.107 tweets por segundo en algunos momentos, sin caídas de proceso ni congestionamientos. InfoQ atribuye (en parte) esta mejora a la migración desde Ruby hacia java:

[ dice Mazen Rawashdeh, VP de Infrastructure Operations Engineering en Twitter]Part of the reason Twitter was able to sustain this level of traffic was down to a set of changes the company has been making to their infrastructure, including, as InfoQ previously reported, a gradual shift away from Ruby to a set of services written in a mixture of Java and Scala and running on the JVM.

InfoQ historia este proceso gradual de migración:

Twitter was at one time thought to be the largest Ruby on Rails shop in the world, and has made a substantial investment in its Ruby stack, going as far as developing its own generational garbage collector for Ruby called Kiji, which, unlike the standard Ruby collector, divides objects into generations and, on most cycles, will place only the objects of a subset of generations into the initial white (condemned) set.
In 2010, however the firm announced that it was shifting some of its development focus. For the front-end the firm followed the HTML5 trend of shifting rendering code into browser-based JavaScript, and, in so doing, it ceased to gain much benefit from Rails' templating model for building web pages. Then, citing both performance and code-encapsulation as drivers, the engineering team re-wrote both its back-end message queue and tweet storage engine in Scala.

 Respecto a los clientes móviles, Rawashdeh dice: As part of our ongoing migration away from Ruby we've reconfigured the service so traffic from our mobile clients hits the Java Virtual Machine (JVM) stack, avoiding the Ruby stack altogether.

Respecto a su motor de búsqueda, también el cambio se inclinó por java: in 2011 the engineering team announced that they had replaced the Ruby on Rails front-end for search with a Java server they called Blender. This resulted in a 3x drop in search latencies.

En años anteriores se comenzó a hablar de Java como un lenguaje legacy, y de su toma por parte de Oracle, como su sentencia de muerte. Sin embargo, ha corrido agua, y la muerte no se produce: Java 7 en marcha, y preparativos para Java 8. En mi experiencia personal, con un uso más extenso de Java, observo estabilidad, confiabilidad, y buena performace. Cada vez que he tenido problemas con la JVM se ha debido a fallos en la preparación de funciones, y he podido contar con buena ayuda de la  consola de java en primer lugar, y de la documentación y la buena capacidad de manejo de errores. Tanto como soporte servidor, como en funciones cliente, la respuesta ha sido normal. Como máquina servidora para aplicaciones web basados en HTML + Javascript, su servicio es transparente y robusto. Y esto, sin contar con su ubicuidad: en cierto modo, "multiplataforma" en mi caso implica Java. En fin, mi experiencia es coincidente con esto dicho en InfoQ.

La ética en la profesión informática

Nuevamente, Javier Garzás se ocupa de la informática en España desde el punto de vista de ésta como profesión. Aunque esta vez, el punto discutido trasciende el perfil de TI en España: es sin duda válido para cualquier medio. Javier propone un "juramento de no compromiso" con una práctica de desarrollo de software determinada, de tal forma que un profesional no adhiera a ultranza con una idea, particularmente en un universo en el que el cambio y la renovación conceptual es frecuente. Dice Javier:

Estoy cansado de la gente que es de una escuela de pensamiento y que rechaza las ideas de otra escuela de pensamiento. Tengo hambre de gente que no le importe de donde vienen las ideas, que les importe sólo lo que significan y lo que producen. Así que se me ocurrió esto del “juramento de no lealtad”.
Esto significa el fin de afirmaciones como “eso no está bien – no es ágil / orientado a objetos / puro / etc.”, en vez de discutir sobre si la idea (ágil o tradicional o impura o lo que sea) funciona bien en las condiciones del momento.
Los anteriores párrafos no son míos, aunque coincido tanto con ellos que es como si los hubiese escrito.
El anterior texto es el “juramento de no lealtad” escrito por Alistair Cockburn hace ya unos años y firmado por muchos profesionales que coinciden con él en rechazar esa mala práctica, tan común en nuestra profesión: casarse hasta el extremismo con una única manera de ver cómo gestionar y desarrollar software, hasta el punto de rechazar cualquier idea alternativa.
Así que si piensas igual, si se te ha pasado por la cabeza más de una vez que hacer y gestionar bien el software no pasa por casarse con una práctica de desarrollo, que una metodología no es ni un equipo de futbol, ni un partido político, ni una religión… que sepas que no estás sólo.

Confieso que, desde el punto de vista de adhesión a ideas, puedo incluírme en el bando de los "comprometidos", porque tengo algunos prejuicios, o quizá prevenciones, respecto a algunas prácticas y también a algunos "marcos de trabajo". Creo tener fundamento para ello, pero soy conciente de que corro este riesgo. Sin embargo, podríamos decir que hasta aquí estamos en un umbral de "autenticidad", es decir, cuando algo se hace por convencimiento, aunque pueda cometer errores gruesos por omisión o confrontación de otras soluciones posibles.
Pero existe algo más, que este juramento alcanza: cuando un argumento es defendido de mala fe. La informática es una profesión, que procura ingresos a partir de un servicio, especialmente para la inmensa mayoría de los profesionales que no son miembros de un grupo académico, o de una organización sin fines de lucro. Quisiera saber cuántos profesionales responsables o gerenciadores de alguna una gran empresa de informática, consultora, o asesora, no tienen sobre su conciencia el haber ocultado un fallo por omisión, una característica problemática en un producto en oferta, una obsolescencia frente a la competencia. Y eso dejando a un lado otras prácticas que caen en el delito, quizá más propias y abundantes en el "tercer mundo informático".
Quisiera ver un colegio profesional capaz de montar un tribunal de ética que condenara prácticas agresivas en la obtención de contratos, o que demandara promesas contractuales incumplidas. El día que así sucediera, les daré mayor valor. En tanto, veo pocas posibilidades de implantar el juramento de no-compromiso en nuestra profesión, y con ello, poco alcance de la credibilidad de un colegio.