Evaluando la comunidad oficial de Plex

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

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

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.

Windows Metro y sus clientes corporativos

Acabo de ver una presentación sobre la evolución del mercado de aplicaciones móviles, que muestra una tendencia abrumadoramente inclinada hacia el crecimiento de la venta de recursos móviles (tablets y teléfonos) en perjuicio de un mercado estancado de computadores de escritorio. Ninguna novedad, así como tampoco lo es que el contenido de las aplicaciones varía radicalmente del que poblaba los PCs de escritorio. Se trata de una verdadera explosión del alcance de las aplicaciones, que escalan al uso diario de cientos o miles de millones de personas. El hecho es que la computación corporativa o de negocios pasa a ser una fracción relativamente estable del mercado total, y, comparativamente, con un crecimiento mucho menor que el resto. Esta es, a mi juicio, la razón que explica el estilo del nuevo Windows 8: salir a luchar por una porción dominante en el mercado de móviles. ¿Estará a tiempo todavía, o estará condenado a compartir una porción dividida con la competencia ya suficientemente establecida? ¿Podría haber sido más adecuado, a partir de un núcleo común, desarrollar dos líneas de producto que respetaran las diferencias de estos dos mundos?
El problema está en el universo corporativo: ¿contempla Windows 8 genuinamente este mercado? Por ahora, por lo que veo, no: Fundamentalmente, lo único que se ha destinado a este mundo es Win32, al que se ha declarado obsoleto. Todas las herramientas y lenguajes disponibles apuntan a soportar lo nuevo, básicamente pensado para dispositivos móviles, poco aptos para el trabajo de escritorio. Ni siquiera, al menos por ahora, es posible arrancar una estación Win 8 en modo "tradicional": usted debe iniciar en Metro, y luego cambiar manualmente de modo: se avecina una pesadilla para todos los administradores de servicios de escritorio que tengan scripts de inicio de sistema...Microsoft desprecia las grandes diferencias que existen entre una estación de trabajo y un aparato de comunicación móvil.
¿Será esta la versión final corporativa? Creo que todavía habrá importantes cambios, y, quizá veamos todavía, en "el Service Pack 2", algo más próximo a lo que este mercado requiere. Entretanto, haga sus cálculos financieros para solventar el cambio, o estaciónese en Windows 7.
Mary-Jo Foley comentaba hace poco lo incómodo del nuevo panorama:

While many love the tiled Metro start screen and are looking forward to using it on touch tablets and PCs, many others aren’t keen on it — especially business users who are convinced that Metro will be nothing but a nuisance, especially on non-touch-enabled hardware, and that they’ll do most of their work in the Desktop app on Windows 8.
Paul Thurrott of Windows SuperSite told me a while back that he believed Microsoft would allow users to get around Metro using a group-policy setting, but when I ran that past my contacts at Microsoft, I was told this would likely not be the case. So in the end, it looks like So who knows at this point whether business users who don’t want Metro may get their wish, after all.
(...)
The other big looming question that many business users want more information about is what they will and won’t be able to do when it comes to managing their Windows 8 on ARM (WOA) tablets and PCs.
Microsoft posted a document for download on February 29 (not sure if intentionally or not) that outlined Consumer Preview features for business users. In that document, Microsoft corroborated word that WOA tablets won’t be able to join an Active Directory domain. Some sites have reported that the document also said that Microsoft wouldn’t allow WOA tablets to be managed at all using Microsoft’s own management tools.
(...)
Charles Fitzgerald, a former Microsoft exec now working at VMWare, noted that the domain join limitation means Microsoft won’t be able to one-up the iPad on this front. (And lack of manageability was one of the themes that Microsoft has advised its salesforce to use in selling agains the iPad in businesses.) From Fitzgerald’s March 1 post:

Lack of domain join “means Windows 8 ARM tablets are going to be consumer devices that don’t integrate with the Microsoft enterprise infrastructure any better than the iPad, so Microsoft loses what should have been a major selling point. You will have to sacrifice battery life and go with x86 to get enterprise features and manageability. This is a big blow to Microsoft’s tablet proposition for the enterprise and WOA may be DOA as a result.

Foley todavía dejaba lugar en su comentario a las novedades que la participación de Microsoft en CeBIT pudiera tener para mejorar este panorama. Hasta donde se puede ver, no ha habido cambios notables.

Java y Metro/WinRT

Windows 8, en su versión orientada a futuro, es Metro/WinRT. Francamente, no sé si Metro será un nuevo Vista, condenado a ser cambiado a una nueva versión tras ser descartado masivamente; sin embargo, creo que está claro que este será el nuevo sistema operativo de Microsoft, con mayores o menores parches o variaciones, después de un mayor o menor paso de tiempo. Y también está claro que el API de Win32 tiene sus años contados, que será considerado "legacy", y que no se deben esperar mejoras futuras sobre él. En estas condiciones, que creo que son irreversibles desde el punto de vista de Microsoft, WinRT debe ser considerado como el futuro del mercado Windows dependiente.
Si esta premisa es cierta, la pregunta siguiente es acerca del universo de productos, lenguajes o herramientas construídas sobre y para esta plataforma: seguramente, algunas que ya hoy han quedado obsoletas, o cambiarán radicalmente, o deberán repensar una tecnología que las suplante, como sería el caso de Flash. Otras, las más, enfrentan un camino complicado. Particularmente, en este momento pienso en Java; no sé si tendrá sentido crear una máquina virtual pensando en Metro como interfaz de usuario (tiles, pantalla táctil), que pudiera quedar a futuro como algo más asociado al usuario final, a tablets, a dispositivos móviles en general. Pero seguramente sí debe comprobarse que una máquina virtual puede ejecutarse sobre WinRT. No he visto todavía ningún pronunciamiento de Oracle ni de otros responsables del estándar, y probablemente pase algún tiempo antes de que haya alguno; habrá problemas de políticas (qué excelente momento para cerrar Windows a la competencia...), antes de resolver cómo enlazar la máquina virtual. por ahora, solo es posible encontrar algunos sencillos intentos de ejecutar java, algunos logrados, pero doy por entendido que estos casos lo han hecho sobre el escritorio (Win32). La siguiente es una pequeña lista de  casos en este sentido:
Ejecutando Java en DOS, claramente sobre Win32,
Lo mismo, en una edición temprana.
Un intento de  instalar Eclipse.
Un intento algo inadvertido, quizá sobre Metro, pero que cae hacia Win32.
Un intento con muchos problemas.

Sin embargo, lo más sustancioso está en otros casos tempranos enfocando Metro/WinRt. Particularmente uno en Google Groups (The Java Posse), discutiendo los problemas de arquitectura (aunque para nada hay que despreciar otro argumento discutido allí: "The real reason is Microsoft pathetically trying to exclude competitors and competing technologies, trying to impose HTML5 for everything"):

So it seems that Windows 8's new "Metro" user environment will make IE plugin-free. Any attempt to use plugins like Flash, Java, Silverlight or anything else, will bring the user to the "old-style" (as in  Windows 7) desktop, which will be seen as a severe experience degradation for users who prefer the new environment.

I am not as much plugin-hater as some people; in my Android smartphone, I certainly appreciate the support for Flash, for simple practical purposes - the rare website that uses some Flash and has no mobile-optimized version or native Android app. And yeah, my karma be damned but Flash works well enough  for me (admittedly on a nice hardware - Tegra2, dual-core Droid X2, rooted & debloated, Flash updated to 10.3).

Still, I love the idea of a plugin-free world, if only for the security improvement. (Including avoidance of trash like "security plugins" mandated by online banking sites...) But this is not really fair if we consider modern browsers that run plugins in separate and low-privilege processes, plus enhanced plugin technology like Google's (Pepper and NaCl / PNaCl), plus plugins for runtimes that are managed and have their own sandboxing and security mechanisms and are sufficiently well patched (candidates: Java, Flash, Silverlight - yes none of them are perfect, they all add some to the attack surface, but the ever-growing browser is already a huge attack surface, there's no single week going without new security bugs being found in every major browser so I don't think the "three big" plugins would make things significantly worse).

There's already people betting that Microsoft will have to back away and maybe, put an option to allow plugins in Metro mode even if not active by default. I know for sure, that corporations are writing new apps with things like Flash, by the thousands. Everybody complains that the corporate world is still dragging its feet with old versions of IE, remarkably the much reviled IE6; but if you think that ActiveX code for IE6 is holding back the web, this is nothing compared to how much stuff depends on Flash. A plugin-free IE10+ will be adopted in corporate world by 2020 with some optimism...

What about the applet tag? This is not part of HTML5 anymore, but it's part of previous versions even if deprecated. This should give Java applets special privileges, at least if Metro-mode-IE will support pre-HTML5 markup (and sure as hell it must, for a long time still). I'm too lazy to install the Win8 beta just to check this, would anybody report if applet [tag] works in Metro/IE? Just curious, I guess it doesn't...

Even in HTML5, there's the [object] tag which is supported and not even deprecated. Will Microsoft break the spec and declare that this feature of HTML5 is not supported in Metro mode? What about Java WebStart, maybe the deployment toolkit can be adapted to detect Metro and not depend on [object], I guess the only fundamental need is the ability to download a JNLP file and launch the associated program? Will Metro restrict such launching too? Both Oracle and Adobe are working on their Plan B for the eventual dominance of HTML5, with new tooling that convert their stuff in plain HTML5. In Oracle's case, there is hope for JavaFX 2.0 if its Web Runtime turns out to be good (it's not yet included in the public beta so I have no idea). There is no similar hope though for old-style, AWT/Swing applets or JAWS apps that will not benefit from a similar Web Runtime.

By the way, the JavaFX Web Runtime (WRT) will be a very interesting test for the claim that Javascript & HTML5 can be fast enough and powerful enough to build any application, competing at least with Java/Silverlight/Flash if not with native apps. Summarizing, the WRT will have a pure-web implementation of the JavaFX frameworks (animation, controls, graphics etc.), I guess using canvas or WebGL and Javascript; and the application code will be (perhaps partially) converted to Javascript code. So, supposing that this WRT is well designed and implemented - and that's a core part of the v2.0 reboot plan so I guess they carefully redesigned the whole thing to make the WRT possible - then if it turns out to be much less efficient than the conventional runtime, this will be strong evidence that the mantra "HTML5/Javascript is fast enough" is bullshit. Let's wait and see.

In another interesting development, Google's technologies like PNaCl and Dart can be powerful enablers for anything that generates Javascript code, from GWT to Adobe's and Oracle's  tools. Dart is supposed to be much more efficient than Javascript, and also, the Java language will probably be much
closer to Dart than it is to Javascript (less sure about AS3...); and I'm sure Oracle and Adobe can write new compilers that emit Dart code instead of Javascript code. Or even, PNaCl code. So if these Google technologies succeed, they can benefit other platforms too. We will still be able to run other browsers in Win8. 

Otra interesante apertura es la expuesta en Iced in code:

The big question now is where does JavaSE fit in all this bold re-imagining? Oracle/Sun have done a great deal of work over the past few years to get Java to work pretty well on Windows and become as natively integrated as possible, but with the re-working of Windows, Java will be confined to the “legacy” application section for the time being, and will not be able to play with the new cool kids in the “Metroverse”. I wonder what steps Oracle  is going to take to make Java still a viable product in the new Windows 8 platform, or will they simple give up and require us all to move to platform specific programming again, like C#?

y alguna acotación de lectores:

First, Oracle should under all circumstances make Java SE compatible with the new platforms like tables, macbooks and metro to keep their concept intact – OR – find a way to easily let Java SE applications run as “apps-likes” under another Java distribution made specificly to these platforms.
Second, Metro is nothing more (or less) than a simple “start-web-page”. Windows 8 is very similar to Windows 7, with program and filesystem seperated – where android and apple are more likely to melt these two things together. Therefore I doesn’t like andorid and apple as their operationsystem are defining the limitations. Some people would call that user-friendliness, I partially agree with that.
I believe that Windows 8 Metro will be an extension to their current desktop on traditional computers, but not a future replacement making the desktop legacy – and we won’t see anything like this within the next 10 years. But Windows 8 Metro will be the beginning of web and computers melting together – and this will eventually make the desktop computer look more like a tablet – and a tablet will look more like a desktop computer – and that will happen!

Uno de los casos que chocaron con WinRT.
Una discusión que refiere a Intel y ARM.

En fin, faltando una respuesta oficial de Oracle, comienza a abrirse el juego. ¿Va usted sopesando el impacto de Windows 8 en sus inversiones en licencias, plataformas, aplicaciones?

Firefox en Windows 8

Firefox anuncia sus planes de desarrollo del soporte para Windows 8. Su plan de trabajo delinea el tipo de dificultades con las que cualquier tercero se encontrará al trabajar para Windows 8 y Metro:

Mozilla’s Brian R. Bondy revealed today that development has begun on Firefox for Metro.

Last month, Mozilla’s Asa Dotzler announced that a Metro version of Firefox was in early planning stages, with a blog post about Mozilla’s goals that in turn linked to a roadmap. Dotzler is listed as the product manager.

Today’s announcement fleshes out some of the key decisions that the Mozilla team has made in the past month.

According to Bondy, Firefox for Metro will mimic Internet Explorer 10’s split personality, as a “Metro style enabled desktop browser”:

Unlike Metro applications, Metro style enabled desktop browsers have the ability to run outside of the Metro sandbox. Meaning not only can we build a browser, but we can build a powerful browser which gives an experience equal to that of a classic Desktop browser.

Metro style enabled desktop browsers have access to most Win32 API and the entire new WinRT API.

Unfortunately a browser can only participate in Metro mode if it is the default browser. So if Firefox is not the default browser on a system, you can’t use it in Metro mode. This is a decision made by Microsoft.

Volveremos sobre la "doble personalidad...

Metro y la herencia de Win32, II

Mientras recopilo información de Windows 8, pensando en el impacto que pudiera tener sobre las aplicaciones existentes (Win32), encuentro estas observaciones de Osvaldo Doederlein, ingeniero en Google:

Microsoft's "squaring of the circle" is by no means perfect: it looks more like an octogon to me. And while I understand and even appreciate the new UI concepts (semantic zoom, layout, typography etc.), its current rendering still looks crude, and (like Peter mentions) the Desktop and Metro look totally alien to each other. Maybe Microsoft can still work on this and make Metro's look more polished, and more similar to the desktop. I like shades, subtle 3D effects, and other decorations that a large display can use (and yeah, OSX uses more elegantly than anyone, though I'm happy enough with Win7). And I'm not visually impaired to need fonts with grotesque sizes everywhere; I'll rather see more data in one screen than need lots of horizontal scrolling (which is really cumbersome on mouse systems). My PC is not a giant Windows Phone!

Now I realize that MS is struggling in the smartphone and tablet markets, and having a single OS and UI that carries over all these platforms will be a big win. Can't really blame Microsoft: Apple is moving in the same direction with Mountain Lion (but not as aggressively as Metro). Even at Google we have Android and ChromeOS, but these platforms are more device-/web-/cloud-centric, and they have no desktop legacy; also, they're not competing on full desktops, to run complex apps like Photoshop (at work, I use Goobuntu for my "macho apps" like Eclipse). The problem is, after years of failure trying to shoehorn the classic Windows into tablets, Microsoft went to the opposite extreme--the total "tabletification" of the PC. Big mistake; there's no reason to believe a device-centric UI will be optimal for a conventional PC, remarkably when running sophisticated applications like IDEs, graghic editors, office suites etc.

Esta es mi especial preocupación. Así como y antes observara respecto a la tecnología de Activex frente al énfasis en .NET, existe un riesgo evidente de que todo el universo de aplicaciones basadas en Win32 y en la interfase visual del Windows [ahora] tradicional, se encuentre ante un futuro de difícil encaminamiento. Por necesidad, volveré sobre esto. Mi cuenta de aplicaciones Win32 a atender es demasiado grande.

Windows 8, WinRT y la herencia de Win32

Este miércoles pasado ha sido un día especial en la pre campaña de lanzamiento de Windows 8: se ha iniciado su "consumer preview", con presentación especial en el Mobile World Congress de Barcelona, y comentarios simultáneos en toda publicación tecnológica que se precie. Sigue resultándome muy curioso que un producto todavía inmaduro, cuyas prestaciones aún no están completas, sea presentado primero a la comunidad de desarrolladores (esto sí es normal) y luego al público en general, tal como está. Sin embargo, puede decirse en este caso en que existe un cambio muy grande en el producto, que puede ser entendible: medir la respuesta, conocer temprano los fallos más gruesos, delinear un mercado de aplicaciones, entusiasmar al cambio. La actividad de difusión entre desarrolladores y socios de negocios ha sido intensa, y sus principales características son bastante conocidas. Desde hace meses se pueden encontrar evaluaciones, comentarios, ensayos, normalmente favorables a Windows 8, y pocas observaciones críticas. ¿No existen reservas críticas sobre los cambios de magnitud que se avecinan?
Sí existen, pero hubiera preferido ver más distanciamiento y criterio en desarrolladores, actores varios de consultoría  y comercializadores, en cuanto al impacto que Windows 8 pueda llegar a tener sobre el mercado actual de usuarios de empresa. Algo que ahora pudiera llamarse un mercado "legacy" o "tradicional", si comparamos lo que hoy usan, y lo que Windows 8 propone.
Partiendo del hecho de que la arquitectura propuesta (WinRT) es diversa y no integrable con la anterior, todo lo que hoy existe está inicialmente confinado al ámbito de Win32, un ámbito sin prioridad de evolución en cuanto a proyectos, y también al momento de ejecutarse. Usted puede construír una nueva aplicación desde cero para ser expuesta en WinRT (y ser aceptada por la AppStore), y se sentirá muy felíz de aprovechar sus ventajas intrísecas y ser de los primeros en el mercado; o tomar su aplicación ahora "legacy" para siempre, analizarla, reescribir todo lo necesario, y portarla a WinRT; o dejarla como está, y confinarla a Win32, es decir, al "escritorio", que ahora es un contenedor subordinado. Lo que está claro es que existe una verdadera ruptura entre las versiones anteriores y la nueva: usted deberá aprender un nuevo API, y deberá replantear cada aplicación, y olvidarse de lo que conocía. Algún comentarista recomienda reconvertir cada actividad diferenciada en un servicio web, para poder ir adelante en la migración. ¿Ha pensado en rever todas y cada una de sus aplicaciones que no sean Office u otros productos nativos de Microsoft?
¿Ha sido la mejor opción definir una arquitectura orientada a recursos móviles como prioridad casi exclusiva? ¿Se ajusta al mercado corporativo? probablemente sí, en el nicho de actividades de movilidad. Pero seguramente no en la mayoría de actividades diarias, atendidas por las llamadas aplicaciones "de escritorio". Este área difícilmente sacaría ventajas del paradigma Metro. Creo que existe una posibilidad de que se repita la situación dada con Windows Vista: una prolongada resistencia a adoptarlo. Tendrá que esforzarse mucho Microsoft para lograr adopcíon en ese área de su mercado.
Presento a continuación algunos análisis, algunos tempranos (último cuarto del año pasado en adelante) y otros muy recientes. Esto es importante porque, como hemos dicho, Windows 8 ES UN PRODUCTO EN CONSTRUCCIÓN, y algunas dudas tempranas se han disipado (y otras han madurado).

Un análisis positivo se puede leer en los comentarios y ejemplos de Harry Pierson (varios). Dos analistas favorables que de todas maneras exponen la magnitud del problema, son Rockford Lhotka y Miguel de Icaza. Lhotka, por octubre de 2011, presentaba una serie de diagramas que mostraban dónde operaban distintas tecnologías, WinRT o Win32. De estos diagramas queda claro que prácticamente todo lo que hoy ejecutamos cae del lado de Win32: Silverlight, WPF, sitios web con plugins (Today’s web sites that use HTML, js, Flash, Silverlight, ActiveX, and other common web technologies all run in the desktop web browser. This is the same as web sites work today in Win7), c++, MFC, ATL, Windows Forms. Y se ejecutan en WinRT casi exclusivamente tecnologías nuevas construídas por Microsoft para Windows 8: WinRT .NET y XAML (I expect this to be the most widely used technology stack for building WinRT applications. The .NET available to WinRT applications is (I think) best thought of as being like .NET on the Windows Phone. It is basically the Silverlight subset of .NET, plus a bunch of WinRT-specific features and capabilities. The differences between Silverlight and WinRT are a bit more dramatic than with WP7, but the analogy remains quite accurate. The XAML is very close to Silverlight and WPF, and the types of code you can write using C# and VB are very comparable to what you can write today using Silverlight); HTML5, WinRT c++. Excepcionalmente, también se pueden ejecutar en WinRT paginas web que consistan sólo de HTML, CSS y JavaScript (If a web site only uses HTML, CSS, and js, then it can run in the WinRT and desktop browsers interchangeably. Microsoft clearly expects this type of web site to become more common over time, though it is interesting that a large number of existing Microsoft web sites are really only useful in the desktop browser)
Resumiendo sus primeras impresiones, Lhotka dice:

Through this series of diagrams, we clearly show how today’s technologies map directly into the Win8 desktop world, still running on the Win32 API. And we show the three technology stacks that enable development of applications on the new WinRT API.
From everything we know today, it seems clear that migrating to WinRT will require effort, regardless of the technology used today, or in the Win8 desktop. Of all existing technologies, Silverlight and then WPF appear to offer the easiest migration. HTML 5, css, and js skills, along with some code assets will also migrate, but there’s a non-trivial architectural difference between web development and smart client development that shouldn’t be overlooked.

por su parte, Miguel de Icaza estudia detalladamente el nuevo modelo enfocado en .NET, y en su detalle podemos dimensionar la dificultad de readecuación a Windows 8 y su API. El API sigue un modelo asincrónico (Microsoft feels that when a developer is given the choice of a synchronous and an asynchronous API, developers will choose the simplicity of a synchronous API. The result usually works fine on the developer system, but is terrible when used in the wild. With WinRT, Microsoft has followed a simple rule: if an API is expected to take more than 50 milliseconds to run, the API is asynchronous); .NET pasa a estar disponible parcialmente en el nuevo modelo (Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT. When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8. And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed)

Invito a seguir sus observaciones, para ir teniendo una idea de cuánto trabajo deberá afrontar en estas condiciones para adecuarse.

Para no abundar, recomiendo la lectura del resumen de dificultades comentada en Techrepublic por Justin James. De las más importantes mencionadas, el modelo asincrónico, la falta de acceso directo a disco, el uso de pantallas táctiles, el énfasis en la nube. Hay más, pero quizá sea preferible que lo lea directamente.

Esto es sólo un pequeño resumen, para que usted piense y estime los tiempos por venir, y vaya calculando decisiones. Una vez más, sería valorable que desarrolladores, implementadores, consultantes, comercializadores, e influyentes en general, se ocuparan del impacto de la adopción del producto, y no sólo del brillo de las novedades. Tras muchos años de hegemonía, también Microsoft tiene un patrimonio "legacy", y alguien debería recordar que eso significa muchas horas de trabajo, y mucho dinero invertido.

Estimando el impacto de Windows 8, parte I

Este último mes me he dedicado a recolectar información sobre Windows 8, particularmente después que la conferencia Microsoft Build develara un buen número de características y planes. Inmediatamente se observa que la nueva versión del sistema operativo trae consigo un cambio drástico respecto a los sistemas anteriores. A primera vista el cambio fundamental es el ¿estilo de presentación/técnica de construcción?, que abandona una larga tradición de interacción con las aplicaciones, introduciendo un modo inspirado o destinado al mercado de tabletas táctiles. Sin embargo, yendo un paso adelante, un cambio más importante está por debajo de éste, y es el que posibilita el funcionamiento de su nueva interfaz de usuario (Metro): el nuevo API, WinRT.
Esta nueva API no se comunica con el API Win32, o no al menos muy bien. Dice Tim Anderson (mencionado por Mary-Jo Foley):

Make no mistake: Microsoft has re-invented the Windows API in WinRT. Just to recap, WinRT is the API for Metro-style applications, the touch-centric, app-centric API for tablets and, one presumes, eventually for Windows Phone (though Microsoft has yet to admit it).
WinRT is only useable from Metro applications. You cannot call WinRT from a Win32 application, nor vice versa*. I think it is reasonable to assume that a future version of Windows which runs only WinRT is a possibility; and that Windows 8 on ARM will look a bit like that even though Win32 will still be there, but mainly out of sight; but I am speculating.
Does that mean Win32 is now legacy? In a way, but such a huge legacy that for the moment we should think of Windows 8 as two platforms side by side.

Miguel de Icaza hace una evaluación temprana entusiasta y optimista (WinRT demistified). Sin embargo, de su comentario sobre WinRT y .Net, dejando aparte las ventajas que Miguel elogia, lo que consigue es abrir nuevas áreas de interrogantes acerca de su impacto.
¿Por qué hablo de impacto? Porque Windows 8 no sale en un mercado virgen, sino en uno en el que conviven no menos de dos clases de aplicaciones, las que fueron planeadas pensando en Windows XP y predecesores, y las que fueron, esforzadamente, movidas a Vista/Windows 7, o escritas para este nuevo y, por lo que se ve, fugaz concepto. Ahora podemos decir que no solo cualquier aplicación del nivel XP/anteriores es legacy, sino que también lo serán aquellas creadas para Vista/Windows 7, dado que ambos comparten el API Win32 (Y estoy tratando de evaluar el alcance de los cambios que impacten en .NET...) Sólo por ese hecho, estarán en una categoría inferior, y espero conocer más adelante las consecuencias de performance que puedan acarrear.
Es decir, debemos mirar el movimiento hacia Windows 8 no sólo desde el punto de vista de las novedades y mejoras, sino de todo aquello que condiciona y obliga a replanear. Este es el punto que ahora me interesa fundamentalmente: considerando el patrimonio de aplicaciones en las que trabajo, si me viera obligado a asumir una migración a Windows 8, debería pensar las alternativas: si soportara Metro, lo mínimo que debiera hacer en nuestros patrones sería contemplar una variante que invocara WinRT en lugar de Win32, y asumir el nuevo tipo de eventos que implica Metro. La separación entre la presentación y la lógica "servidora" sería manejable, así como los lenguajes de implementación (Esto vale para cualquier variante de interfaz de usuario). Si no soportara Metro, poco cambiaría o nada, pero los problemas estarían en el ambiente: estaría ejecutando aplicaciones en un ambiente "no preferente".
Finalmente, siempre queda la alternativa simple de desechar la interfaz del sistema cliente, y usar java. ¿cuál se supone que sería la alternativa más rápida y confiable?
¿Cuál supone usted que sería la alternativa que una corporación usaría si tuviera que pensar en la transición de sistema operativo de Microsoft?
Los reclamos de la comunidad de Silverlight pueden ser pálidos reflejos del impacto del cambio generalizado sobre el mundo corporativo. Especialmente si las politicas de actualizaciones de Microsoft comienzan a establecer presión hacia el cambio.

El contínuo ser o no ser de IBM con el AS400

Bob Cozzi, veterano experto en el AS400/iSeries/System i, comenta la errática historia de soporte del AS400 por parte de IBM, concentrándose en el punto que constituyera su peor decisión estratégica sobre el impecable AS400: no desarrollar una presentación gráfica, ni salir jamás al cruce de quienes pusieran el acento sobre este aspecto para discutir de "modernidad":

Bill Gates & Co. were right: graphical user interfaces (GUIs) are "better." Today we know that in the mid-1990s IBM Rochester had the opportunity to move the operating system to a graphical-based user interface. This was happening around the same time as the move of OS/400 to the PowerPC chipset. This move gave OS/400 the platform the performance boost it so badly needed. But for some reason, IBM decided against a GUI for the i platform. This wasn't a simple "thumbs up/down" vote, however. I have heard it was a heated debate that came down to this: "our customers have so much invested in green screens it will be difficult to get them to change."

Of course this was nothing more than the classic: "we've always done it this way so why change now?" I have also heard there was concern about performance. It would have taken a lot to put a native GUI on the platform, but would it perform? If they created dumb-head terminals, (which they did) and allowed a GUI to run on those (which they did) and then allow them to be attached to the i platform (which they did), then the GUI engine could be outboard (off the main system) and therefore not impact performance (which they didn't do). Two retired IBMer's (the same ones who built the original 5250 data stream in the 1970s) independently leveraged all that technology IBM created and didn't use and enable support for a native GUI on the i platform. This happened at least 12 years ago—perhaps more—and it worked great. But on the i platform, unless IBM gets behind a technology (they did not) rarely does it have long-term success. So the two former IBMers stopped selling their GUI just a few years ago.

If IBM had created a GUI and advocated the platform as an end-user product with a server option (like everyone else seems to be doing), then it could have been i from the end-user desktop to the server farm and everything in between. The IBM POWER-based Cell chips used in Nintendo and other video gaming consoles make graphics scream—more than enough power for OS i GUI support. Imagine the graphical performance boost we would have had when Cell came out and was added to the i platform.

It was Lou Gerstner, one of the most respected IBM CEO's of all time, who, in my opinion, made one of the worst decisions any IT industry CEO of all time. What is it? Gerstner said "When something becomes a commodity we won't be in that business." Well, Lou, today all IT hardware is "a commodity," so now what?

Pero Cozzi no habla de esta ya demasiado discutida cuestión porque sí. Lo hace porque sin duda este paradigma a devenido igualmente "obsoleto", y la arquitectura que ahora generalizadamente es discutida como más idonea está basada en la web. Su pregunta es si ahora IBM está dispuesta a explotar este cambio, que por otra parte está disponible en el AS400 desde hace mucho tiempo (la primera vez que abandoné un Internet Information Server en favor del básico HTTP server del AS400 sucedió hace alrededor de diez años).
Sin embargo, del tono de su argumentación se desprende algo adicional: el problema con el cambio no sólo proviene de IBM, sino de su base de usuarios, y de su nivel gerencial de usuarios. Sólo un cambio político de IBM podría generar otra persepción del equipo y sus posibilidades:

Today, GUI means browser-based user interfaces. You can build GUI applications for i (iGUI as I call them) using RPG, HTML, JavaScript, and PHP, so there is no excuse to allow those Microsoft weenies into your shop to take away your job.

The i is so reliable and trusted over other platforms that it's now being installed all over the world in countries such as Russia, where industries like banking or gas and oil are fast-growing industries. Those systems and applications need to be not only reliable, but secure—secure not just from outside attacks/hacks but from untrustworthy in-house employees. Recently I visited several banks in Russia and I saw i running in these banks. When this kind of security is required, nobody screws around with Windows, and Linux is just too labor intensive to be used efficiently.

Remember, when you have tens of millions, or hundreds of millions, or in some cases, billions of records in the database, those other platforms that a Microsoft-weenie boss might be using at home on his 12-record checkbook application just don't scale up for use in a real-world environment. If he or she is impressed with a sexy WYSIWYG GUI application they use at home, it is your job to let them know the i platform and RPG IV also support GUI applications.

When your company wants a new application, strongly suggest that it be written with a browser-based user interface.

When your company refuses based on "all the other applications are green screen", you must refuse their "we've always done it this way" argument and push for an iGUI solution.

If your company still refuses, suggest that they allow you to write the new application in both green screen and iGUI versions—this will let them see what the i is capable of doing and give you the much needed GUI experience. Remember, you're first five to 10 web-based iGUI applications may not be very user-friendly; you are a programmer, after all.

When your company still refuses, then write the green-screen application and, covertly (perhaps on your own time) write the same application using an iGUI interface. Then when you roll out the app, suggest that they take a look at the browser-based version as well.

If they still refuse, then accept it and continue this practice for the next four or five applications. Then when the new VP of IT is hired and says "green screens are old, we're going to Microsoft" you can say "we've got GUI versions of these applications already". So the "i" suddenly doesn't look so old.

If they still refuse, at least you'll have some web browser-based, iGUI application experience to add to your resume.

Esta larga historia de olvido del desarrollo de una interfase de presentación gráfica ha sido siempre reemplazada por terceros: en primer lugar, al margen de IBM, que probablemente haya perdido un volúmen de ventas incalculable. Y, en el marco del mercado del AS400, por el desarrollo de herramientas de terceros, en general de generación automática de código, o de desarrollo basado en modelos. Dentro de IBM, por su compra de Rational; fuera, por productos como Plex, que naciera con dos propósitos: generar una interfase gráfica para su esquema ya existente de generación de código para el AS400 (2E), y para trascender este mercado, y generalizar el desarrollo basado en modelos a arquitecturas abiertas.

Algo más sobre Open Access en RPG (y el i 7.1)

Continuando con los anuncios del i 7.1, sucesor actual del AS/400 (perdón, iSeries, etc), Scott Clement publicó el 22 de este mes un artículo en System I Network, que también destaca las principales novedades y virtudes del nuevo sistema. De entre los distintos puntos destacados, nuevamente destacamos las referencias a los cambios en el RPG, fundamentelmente el concepto de Open Access:

Rational Open Access: RPG Edition

The biggest RPG feature of 7.1 is RPG Open Access. Open Access (previously referred to as "Open I/O" in early discussions) makes it possible for programmers to write "handlers" that take the place of file I/O when you use RPG's native file opcodes.

The way George Farr explained it, under the covers, anytime you read or write from a file, RPG actually calls a routine in the OS to handle that request. For example, if you CHAIN to a record in a PF, RPG calls a routine in the database manager that retrieves a record by key. Similarly, when you use EXFMT to display a screen, it calls a routine in the display file management portion of the OS. So while we tend to think of these operations as "reading a file," the RPG runtime is really just calling a routine.

What IBM has done is open those routines up to you. You can now have it call a routine of your choosing rather than one provided by the OS. That way, you have full control over what happens when the program tries to read a file. Will it actually read a file? Or will your code simply calculate the value returned for the fields in the record? It's up to you.

People are excited about this new tool because it makes it possible for existing RPG code to use opcodes like EXFMT, READ, WRITE, etc., against a display file—but they can provide the routines that handle the display I/O. So the routine might decide to display a web page instead of a display file. Or it might decide to communicate with a Visual C++ program running on Windows, and that Visual C++ program might bring up a GUI window.

Third-party vendors are already providing prewritten handlers that RPG Open Access can call. So if you want your RPG programs to output to the web instead of outputting to a 5250 terminal, you can buy a "web" handler from a vendor, pop it in, and your program now goes to the web!

If, in the future, you want your output device to be an iPhone or iPad or Droid, it's just a matter of buying a new handler. The only change required to your RPG program is the F-spec, where you'll need to code the HANDLER keyword to tell it where to call the handler routine.

Unfortunately, I don't really have the space to go in-depth about RPG Open Access. That's something that could easily fill an article by itself. Or several articles! But if you'd like to see a more in-depth technical description, I suggest that you check out the technical documentation on the RPG Cafe.

RPG Open Access is not included with the RPG compiler, however. Instead, you have to purchase it separately from IBM. So, unless you plan to write your own handlers, you're going to need approval for two different costs: Open Access itself, plus whatever the vendor is charging for their handler.

On the plus side, it's available for both 6.1 and 7.1, so you don't even have to wait till 7.1 before you can try it out.

Sin embargo, Scott mantiene sus reservas sobre el alcance de Open Access, cuestionando su verdadero nivel de cambio, al no modificar esencialmente la arquitectura:

My opinion is that Open Access is overhyped. It has been represented as the greatest thing ever and the salvation of the RPG language, and in my opinion that's blown way out of proportion. All it does is enable a new way of calling subprocedures in a service program. Instead of calling them directly, you do file opcodes, and the file opcodes call the procedures.

Plus, the existing SPECIAL file support, although limited, never got a lot of adoption in the RPG community. So why come out with new tool that's almost identical to a tool that's hardly used? Is there really that much demand for it?

Furthermore, from the RPG program's perspective, it's still reading/writing a display file. Even though you may have another device on the other end, RPG doesn't know that, and so it can't take advantage of it. It can't behave like a proper web application, because it's trying to control the flow and act in a stateful manner. It can't behave like a proper GUI program, because it can't take action based on mouse events or what keystrokes a user typed into which custom controls. All it knows is how to read/write data to a display file. And we basically already had the same thing with screen scrapers, didn't we? I realize that Open Access is intercepting the program logic at a different level than a screen scraper would—but other than that, isn't it still doing the same thing? Transforming a DDS-defined 5250 screen into a GUI screen, while tricking the RPG program into thinking it's still 5250?

No obstante, la idea me resulta más que interesante. Poner fuera el destinatario/orígen de una lectura/escritura, abre posibilidades. Es cierto que esto puede ser especialmente útil para terceros proveedores, pero justamente, es probable, desde mi punto de vista, que sea posible sacarle provecho a través de Plex, con la misma licencia, y código basado en patrones.

Más allá de los apuntes sobre Open Access, Scott resume otras novedades, tanto sobre RPG como sobre herramientas de desarrollo, licencias, almacenamiento. Para la consternación de muchos desarrolladores, el entorno de desarrollo basado en PDM, SEU, SDA, RLU, DFU, se acerca cada vez más a su fin. No quedará otro remedio que acelerar el uso de las nuevas IDEs...

En la wiki de Plex: user interface gallery

Para usuarios de Plex: Se introdujeron algunos cambios a la galería de estilos de presentación de paneles que se publica en la Wiki. No está de más hacerle una visita, y comprobar las posibilidades existentes, y la variedad de patrones disponibles. Para verlos, ir a la página en la wiki.

Una apropiación útil de Twitter

El primer uso publicitado para Twitter fue el de "blog minimalista". Un uso que parecería sólo adecuado para la poesía japonesa...Pero el real valor del servicio parece haberse encauzado hacia la conformación de corrientes de noticias, o redes de diálogo orientados a atender un evento, es decir, actividades que requieren flexibilidad y rapidez.

Dentro de este esquema parecería caber adecuadamente el uso en actividades financieras, tal como describe Bianca Pinto Lima en América Economía.

“‘Compra con el rumor y vende con la noticia’ es uno de los dichos más antiguos de Wall Street, y cualquier herramienta que mejore la velocidad o la calidad de la transmisión de la información interesa a los inversionistas. Twitter hace eso”.Esa es una de las razones citadas por Mark Palmer, presidente de StreamBase, en su blog, para que la nueva red social se considere una aliada del mercado financiero.La empresa estadounidense de tecnología de la información lanzó en junio una actualización de su software de análisis de datos CEP (Complex Event Processing), que permite filtrar y analizar en tiempo real, además de los medios tradicionales, la información que circula en Twitter
[...] Creado este año, el microblog de InvestBolsa (sistema de Home Broker de la corredora de bolsa Spinelli) ya posee más de 1.400 seguidores, y suma entre 20 y 30 nuevos miembros todos los días. “Twitter fue muchas veces el primer canal para divulgar información, incluso antes que los medios tradicionales”, destacó el responsable del área de Home Broker de Spinelli, Rodrigo Puga. Para no ser víctima de manipulaciones, Puga aconseja que el inversionista busque fuentes creíbles y que siga microblogs de empresas respetadas. “Personas con más seguidores tienen más credibilidad, y acaban transformándose en una opinión de peso para cualquier mercado, incluso el financiero”, afirmó.

Pinto Lima menciona StockTwits, como caso de uso en este sentido:

StockTwits, una nueva herramienta creada en Estados Unidos, sirve para facilitar esa búsqueda. La comunidad utiliza la misma plataforma de microblogs de Twitter y permite que inversionistas intercambien información rápida en tiempo real, sobre qué acciones están comprando y vendiendo, además de datos del mercado y posibles tendencias. En este caso, la pregunta que se debe responder es: ¿qué estás negociando? La ventaja es que la comunidad da la posibilidad al internauta de crear sus propios filtros, o sea, que reciba información sólo de determinadas acciones y de las fuentes que considera más confiables.

Twitter en la comunicación con el cliente:

“Hace algunos años, las empresas discutían la posibilidad de tener una parte del sitio dedicada a la relación con el inversionista, ahora eso es un lugar común. De aquí a un tiempo, las empresas utilizarán medios sociales para relacionarse con el inversionista, lo que también será un lugar común”, afirmó el director de comunicación del Instituto Brasileño de Relaciones con Inversionistas (Ibri), Luis Fernando Moran de Oliveira.
El Ibri creó un microblog en Twitter hace tres meses, y hoy cuenta con 115 seguidores. Entre las ventajas de la herramienta, Oliveira enumera la capacidad de hablar con muchos al mismo tiempo y la certeza de que las personas están interesadas en lo que se habla, “al final, ellos escogen seguirte”. “Eso disminuye el ruido en la comunicación y aumenta la eficiencia”, sostuvo el ejecutivo.

Por supuesto, esto es un ensayo. Su principal inconveniente es la inseguridad. Así, los casos destacados apuntan a grupos cerrados y con relaciones de confianza. Sin ésto, un consejo de inversión tomado desde este medio podría ser suicida.

Críticas a MDD desde dentro: Rigidez del código, parte II

Tratando de completar las ideas que el primer punto de Johan sugiere, quisiera volver sobre el carácter abstracto de MDD (The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't change every little detail you want).
Muchas de las objeciones atribuidas primero a MDA, pero luego extensibles a MDD (la visión ampliada y variada del diseño basado en modelos), están aquí. El primer acusado es UML, el estándar definido por OMG primero como herramienta de modelado, y luego como soporte para expresar modelos traducibles a código. ¿Es suficiente UML para expresar de manera abstracta toda la lógica de un sistema? ¿Es posible bajar en el nivel de detalle de un sistema recurriendo sólo a las herramientas propias de UML (vistas de diagramas y OCL)? Estas objeciones provienen especialmente de quienes usan o discuten MDA; sin embargo, no escapan a estas preguntas las variadas alternativas de solución ajenas a MDA (Johan describe algunas de estas variantes).
MDD, en sus distintas vertientes, probablemente esté atravesando un período parecido al que atravesara UML en la década de los 90: distintas notaciones se fueron forjando para expresar el diseño orientado a objetos, convergiendo en un esquema consensuado y no propietario, suficientemente potente como para responder a su tarea. El desarrollo de aplicaciones basado en modelos abstractos y generables, capaces de aplicarse a distintas plataformas y a distintas arquitecturas, mejorará sus herramientas y logrará mejores resultados. ¿El esquema de extensiones de Eclipse podría ser una respuesta a la apuntada "falta de flexibilidad"? ¿Alguna variante de DSLs aplicados en el espacio hoy llamado "rígido" podría aumentar la granularidad de los sistemas?
En el caso de Plex (mi herramienta de trabajo, para cualquiera que lo desconozca), este espacio está cubierto por el concepto de "diagramas de acción": llamémoslo un script abstracto, capaz de moverse en un meta nivel materializable en distintas encarnaciones, fuertemente restringido por los objetos a los que sirve (no es posible referirse a ningún objeto que no esté definido en el modelo, ni violar los tipos que manipula), que puede sin embargo ser detallado y minucioso. ¿Es una solución definitiva? No, porque globalmente podría llegar a expresar en un conjunto de diagramas algo contradictorio con el comportamiento esperado del modelo. No es sustituíble el trabajo del diseñador para expresar su modelo; un mal diseño también puede ser plasmado en un modelo escrito con UML.
En fin, digamos que el punto 1 de los ocho enumerados por Johan den Haan, pone el acento en un problema en discusión, que está en el laboratorio. Y que probablemente se refinará y quizá incluso desaparezca. Sin duda, en primer lugar, su objeción a la calidad de la interface gráfica.
En los próximos días seguiremos con otros puntos...

Críticas a MDD desde dentro: 1, rigidez del código

Desde hace pocos meses existe el foro The Model Driven Software Network (como aquí se comentó). En breve tiempo ha desarrollado un buen cruce de ideas, atrayendo a muchos de los teóricos, constructores, y poseedores de los distintos "sabores" en que se trabaja hoy en desarrollo basado en modelos. Curiosamente, en varias ocasiones se ha discutido allí en tono pesimista, poniendo acento en las dificultades que este tipo de desarrollo implica, pero dejando aparte lo que de positivo y productivo tiene. Probablemente, porque esto se da por sobreentendido, y a quienes construyen les interesa resolver los problemas en primer lugar.
En este contexto, en los últimos días dos miembros del foro han aportado algunas razones de las dificultades propias de MDD: Johan den Haan, que resume ocho razones por las que MDD es peligroso, y Peter Bell, puntualizando la importancia de la selección de un meta-metamodelo.
Particularmente las observaciones de Johan se han discutido más de una vez en TMDSN, y pueden servir de base para conversar sobre estos puntos críticos. Dado que el tiempo es escaso, conversaremos un punto por vez. Y el primero será la referencia a la "rigidez del código":

"If you're used to programming everything by hand, MDD can be quite rigid. The goal of MDD is to ‘program' on a higher level of abstraction. This means that you have to specify less and generate more. However, this also means that you can't change every little detail you want. It is, for example, often the case that generated graphical user interface are inflexible and they all look like each other."

Johan menciona aquí por lo menos dos aspectos: las características del código, y las de la interfaz gráfica. Particularmente el aspecto de la rigidez del código, de una u otra forma, es uno de los más discutidos en TMDSN, y donde se proponen soluciones más abiertas. En varios casos se cuestiona la limitación del código generable, por su incapacidad de alcanzar más allá del marco estático de un sistema. Al llegar al comportamiento (behavioural model) parece entrarse en un terreno abierto e inconcluso. Distintos caminos, algunos más "rígidos" que otros.
En cuanto a la interface grafica de usuario, que básicamente podría pertenecer al modelo estático, dificultades para definirla con el grado de detalle que se desee deberían considerarse limitaciones de la herramienta particular con la que se trabaje.
Pero volviendo a la posible "dureza" del código, esto tiene dos aspectos: la capacidad del modelo de expresar un problema, tan flexible y detallado como se requiera, y la calidad del código generado al transformar el modelo en código ejecutable. Es mi parecer que la herramienta que se use debe ser capaz de modelar el problema, y que si no lo logra, es incompleta. Estoy seguro de que casi todas las existentes son capaces de expresar una solución tan completa y articulada como se requiera. Y que esta capacidad puede refinarse progresivamente para ser todo lo dúctil que haga falta. Por otra parte, sin duda será rígido el código final ejecutable que se genere: Dado que el código proviene de las transformaciones preestablecidas entre el modelo y el código fuente resultante, éste siempre será escrito de la misma forma para los mismos elementos de modelo que "traduzca". Si bien eso es cierto, también es cierto que se trata de código probado, y que siempre será igual de confiable. Por supuesto, el todo generado no necesariamente será optimizado o seguro, pero esto es solucionable en un nivel más general: siempre es posible (y necesario) optimizar las transformaciones. Usualmente estas transformaciones son modificables, y, aún más, en muchos casos se trata de contrucciones "ad hoc". De paso, a mi entender, esta es la única vía de refactorizar en el desarrollo basado en modelos.
Donde se puede hablar de problemas con el código, es en el modelo dinámico (behavioural model). Muchas herramientas generan sin dificultad el modelo de clases, pero allí se detienen, requiriendo completar el comportamiento mediante extensiones construídas con programación estándar. Eclipse es preferido por muchos por su modelo basado en extensiones, y la posibilidad de integrar estas (construídas en código java en general) con el modelo al que soporte. Sin embargo este no es estrictamente el punto cuestionado por Johan. Lo tomaremos en otro momento...
Queda más por conversar. Recapitularemos en la semana.

Para tener una guía: Historia del diseño de interface gráfica

Con poco tiempo disponible, de entre todo el material que leo y clasifico, quisiera destacar la recopilación de Gyorgy Fekete publicada en WebDesignerDepot en marzo de este año, historiando las distintas tentativas de crear una interface gráfica al sistema operativo, desde 1981 hasta hoy. A la recopilación le hubiera venido bien una fundamentación de las distintas líneas de análisis del problema, y de las corrientes principales históricas (particularmente una línea abierta para POSIX hubiera ayudado a visualizar las líneas existentes en la industria). También hubiera sido interesante presentar este recorrido gráficamente, a modo de un árbol darwiniano. Como en zoología, no todas las buenas ramas tuvieron éxito...
En mi caso, mis primeras actividades fueron sobre el Mac Os 1.0, Windows 2.0 y AIX ¿y en su caso?
El crédito del encuentro de este artículo es de André Furtado, a quien sigo en del.icio.us desde la época de su graduación en Brasil, debido a su interesante trabajo sobre software factories. No viene al caso, pero debiéramos seguir un poco más el trabajo de las universidades brasileras.