domingo, noviembre 20, 2011

ERPs: Aviso a navegantes

Este es un asunto importante, que entra en el terreno de la ética: la credibilidad que puede esperarse del consejo de una empresa que vende un producto de software (en rigor, esto vale para todo vendedor). Es  interesante ver que las observaciones que siguen a continuación vienen de una consultora de primera línea: el comentario está originado en la presentación de Dennis Gaughan en la Conferencia de Gartner Australia, esta semana pasada. No tenemos el contenido directo de su presentación, pero sí su resumen tomado por dos publicaciones de tecnología, al menos: Business Insider, e IT News de Australia.
Esta es la nota en Business Insider:
The four big software vendors -- Microsoft, Oracle, IBM, and SAP -- have hidden motives that customers need to understand, otherwise they might be pushed into buying products and services that don't fit their needs.
That's the takeaway from a recent Gartner talk in Australia, reported by IT News.
At a symposium this week, Gartner analyst Dennis Gaughan explained what the four big vendors are really trying to do, based on Gartner's experience with its clients.
  • Microsoft mainly wants to protect Windows and Office. Microsoft is a platform company, and its main goal is to protect its highly lucrative Windows and Office monopolies, while establishing other platforms that will be hard for customers to break away from later. New functionality is "drip fed" to users of those core platforms, but new products exist to protect the core. He advised extreme caution before moving to Office 365, and said not to slip into an "all-Microsoft" mentality.
  • Oracle products don't really work well together. Oracle's sales force is extremely aggressive about pushing a suite of products, but has much fewer integration points than SAP. In fact, integration is usually left entirely up to the customer. Oracle is also very reluctant to talk about product roadmaps for fear that future products will cannibalize existing ones. The company makes more than 90% of its profits through maintenance fees, and will do whatever it takes to keep those fees flowing in. Gaughan also expressed some surprise that so many customers keep working with Oracle despite reporting that Oracle is "the most difficult vendor to deal with."
  • IBM wants to take over your IT strategy. IBM bills itself as a thought leader, but its real business is selling consulting services. To thrive, IBM account managers try to take control of a company's IT strategy so they can keep pushing new products. Gaughan recommends taking a collaborative or partner approach.
  • SAP confuses customers with pricing. A lot of SAP customers ask Gartner for help figuring out SAP's pricing and licensing, as SAP has unusual terms for billing data going into and out of systems. Gaughan also said that a big technology transition that was driving SAP revenue for the last few years -- moving existing customers from the old R/3 system to the newer Business Suite -- is almost done, which means SAP will have to be more aggressive with maintenance fees. He recommended locking in maintenance prices now.
Overall, Gaughan said that most of the innovation being done in these companies is in their research arms. Their real goal is protecting the status quo for as long as possible.
 Frecuentemente, las empresas son conducidas a compras que, especialmente en el campo de ERPs o grandes infraestructuras de hardware, pueden llevarlas a gastos interminables e inabordables, y luego, a un fracaso difícil de levantar. Frente a la idea de la visión del software como un commodity, algo que se puede tercerizar, estoy convencido que una compañia mediana o grande debe defender y capacitar sus recursos humanos tecnológicos, y debe defender un punto de vista y una estrategia propia, confrontada, si, aceptando la consulta de terceros, pero con capacidad de maniobra e independencia de criterio. No todas las estrategias son adecuadas para cada caso.
De aquí se derivan dos o tres líneas de discusión, que trataremos de seguir: el valor de un ERP "empaquetado", la encrucijada de la implementación de un ERP, la ética esperable de una consultoría. Será en el futuro, si es posible.

jueves, noviembre 17, 2011

Críticas a OOP

James Hague, programador funcional (o por lo menos por un tiempo), interesado en Python y Erlang, hablando del primero, hace una referencia a la programación orientada a objetos, puntualizando lo que lo aparta de oop:
 (Don't Distract New Programmers with OOP) 
[...] The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture. That's easy to see just by comparing a procedural Python program with an object-oriented one. The latter is almost always longer, full of extra interface and indentation and annotations. The temptation is to start moving trivial bits of code into classes and adding all these little methods and anticipating methods that aren't needed yet but might be someday.

When you're trying to help someone learn how to go from a problem statement to working code, the last thing you want is to get them sidetracked by faux-engineering busywork. Some people are going to run with those scraps of OO knowledge and build crazy class hierarchies and end up not as focused on on what they should be learning. Other people are going to lose interest because there's a layer of extra nonsense that makes programming even more cumbersome.

At some point, yes, you'll need to discuss how to create objects in Python, but resist for as long as you can. 
Esta nota de Hague es de marzo de este año. Por casualidad o no, ese mes otro entusiasta de la programación funcional desacredita totalmente oop. Y nada menos que en un curso introductorio de Carnegie Mellon.
Sería muy interesante conocer un balance del curso terminado.

lunes, noviembre 07, 2011

La década de Eclipse en InfoQ

Hablamos en octubre de los diez años de historia de Eclipse, pero el artículo de InfoQ editado hoy es interesante por su crónica histórica, que destaca el gran aporte de IBM desde el comienzo:
Ten years ago today, an open-source Java development environment called Eclipse was released for both Windows and Linux. Eclipse 1.0 is still available for download for Windows (98/ME/2000/NT) and Linux (RH 7.1), along with translation packs (also provided by IBM).
The Eclipse consortium itself wasn't founded until 29th November 2001, and the Eclipse Foundation wasn't created until 2nd February 2004; so today marks the 10th anniversary of the initial release of the software rather than the organisation itself.
Eclipse 1.0 was the result of a $40 million valued donation of source code by IBM. Back at the turn of the millennium, there was a plethora of Java development environments available, such as Symantec VisualCafé, Borland JBuilder and IBM's own Visual Age for Java. However, as predominantly Java-only environments, they did not cope well initially with the advance of Servlets and HTML pages (and later, JSPs). In particular, IBM's Visual Age for Java used an object database to store source code instead of files; so it was not able to develop the nascent Enterprise Java applications that were becoming increasingly popular.

(...) 
With the initial release of IBM WebSphere in June 1998 (at that time, just a Servlet engine), IBM needed a development tool to be able to complement its existing Java development tools. IBM developed WebSphere Studio to provide the HTML editing, released as far back as September 1998 with the combined release of WebSphere Studio 1.0 and WebSphere Application Server 1.1. WebSphere Studio would go on to form the foundation of Eclipse 1.0, and on 5th November 2001 was announced:
IBM's new WebSphere Studio tools are the first commercially available tools built on open source software, code-named Eclipse, which is being donated by IBM to a new community of software tool vendors. Developers working on WebSphere Studio and other Eclipse-based tools use a common, easy-to-use interface that provides a consistent "look and feel," regardless of vendor, which cuts training costs for customers.
At the time, IBM was losing developers from its flagship Visual Age for Java product. A new breed of development tools – such as Apache Ant, which was publicly released as version 1.1 in 19th July 2000 – operated purely on the Java source files. As a result, Visual Age was not able to take advantage of these or other tools built around creating dynamic websites. Other commercial tools were gaining in popularity, but each offered a slightly different interface and actions. Whether IBM's decision to release the core of WebSphere Studio as open source was driven by a means to increase familiarity with its commercial products, or whether it was a foresighted decision to enable greater collaboration between competitors, the release of Eclipse achieved two specific goals; it became a de-facto Java IDE and went on to become an organisation and tool chain supported by a multitude of different companies.
It's also worth acknowledging that Eclipse wasn't the first open-source IDE for Java; NetBeans was open-sourced in June 2000. However, whilst NetBeans was based on the less powerful (at the time) Swing, Eclipse was based on an entirely new widget toolkit that adopted the OS's own native widget set for displaying the user interface. Over time, this speed discrepancy has reduced; although SWT continues to provide better native integration than Swing renderings as operating systems have evolved.
The only other commercial Java development environment to survive from the period was IntelliJ, released in January 2001. All of the other significant commercial efforts either folded or moved towards running on an Eclipse runtime. 

 (...)
The Eclipse Consortium initially consisted of Borland, IBM, Merant, QNX Software Systems, Rational Software, RedHat, SuSE, and TogetherSoft. Initially released under the IBM created Common Public License, the platform initially focussed on the Java platform with code taken from the WebSphere Studio product, which itself grew out of Visual Age Micro Edition.
Visual Age for Java was both based on and implemented with Visual Age for Smalltalk. It was not until J2ME development with the re-implementation of Visual Age for Java as Visual Age Micro Edition that the toolset was re-implemented in Java, which went on to become WebSphere Studio and then Eclipse. Visual Age for Smalltalk was inspired by the Interface Builder in Nextstep. It's also worth noting that this was all done by the Ottwa-based Object Technology International, which was acquired by IBM in 1996, which is why many of the Eclipse committers, and indeed subsequent foundation, are based in Ottwa, Canada.
With Borland, Rational and other traditional Java developers behind Eclipse, it quickly took off, reaching an average 4000 downloads/day in the first month. (IBM would later go on to acquire Rational Software during December 2002–February 2003.) QNX aimed at the embedded market, and joined in to provide CDT 1.0 in March 2003, after less than a year's development. Today, Java still leads the development pack with CDT running a close second.

miércoles, noviembre 02, 2011

WinRT en el laboratorio...

 Rafael Ontiveros publica un interesante artículo sobre WinRT, tratando de adivinar las características de un producto que todavía es más trabajo de mercadeo que realidades. Aprecio su interés por ir a las cosas mismas, antes que adherir a las alabanzas tempranas. Fundamental, pone en duda el alcance de WinRT:
WinRT y Metro se ejecutan, como todo lo demás, sobre Win32, con las ventajas y los inconvenientes que eso pueda tener. No me malinterpretéis: no hay nada malo que la arquitectura sea diferente a la indicada en el gráfico de arriba, lo que está mal es que Microsoft nos mienta tan descaradamente. Simplemente eso.
Si lo han hecho así, por algo será y sus motivos tendrán, y es entonces cuando, ya definitivamente, yo tenía razón: Windows ya no es Windows NT, y su grandiosa arquitectura por bloques se ha perdido en el camino. Y esto sí que es malo, bastante malo, porque estamos volviendo a un batiburrillo de código como es, por cierto, el OS X (quizás algún día hable de ello).
Vosotros mismos podéis comprobarlo sin problema alguno y de forma muy rápida. Tenéis que construir dos aplicaciones, una WinRT en C++/CX y otra clásica de Win32. No hay más que utilizar las plantillas por defecto sin ningún cambio.
Eso sí, hay que hacerlo a partir de la versión Developer de 64 bits de Windows 8, e instalar una versión de la MSDN, porque la Express creo que no es capaz de generar programas Win32 puros.
(...) He llamado “TestWin32” a mi aplicación tradicional, que genera una ventana de Windows normal y corriente utilizando directamente el API de Win32. A la Metro la he llamado “TestSplitApplication”. Una vez generadas, tenemos que compilarlas.
(...) Si ahora nos vamos a la carpeta en donde está almacenado el proyecto (que podemos hacer desde el mismo IDE posicionándonos en el nombre de la solución en el Explorador y elegimos Open Folder in Windows Explorer), carpeta Debug, encontraremos el ejecutable del programa nativo (TestWin32.exe) y dentro de la carpeta TestSplitApplication, el de la aplicación Metro.
(...) Si nos diera por abrir, por ejemplo, uno de los dos KERNEL32.DLL, veríamos que ambas DLL son la misma con las mismas dependencias y exportaciones. Por lo tanto, ambas aplicaciones dependen del mismo subsistema.
Reitero que es una tontería, pero no lo es cuando intentan engañarte.
Lo que sí parece han hecho ha sido romper KERNEL32.DLL en otros ficheros más pequeños que contemplan subconjuntos de lo que en versiones anteriores había en él. Quizás de esta forma reduzcan la huella de memoria evitando cargar sub ficheros cuando estos no se vayan a utilizar.
(...) 
Esto nos lleva a un tercer problema: parecer ser que una aplicación Metro no puede ejecutar funciones de Win32, y una de Win32 tampoco de WinRT.
¡¡Pero si es el mismo subsistema!!
Pues bien, estamos ante una limitación artificialmente impuesta por Microsoft sin ningún motivo técnico aparente… con lo guapo que sería hacer aplicaciones Win32 con C++/CX…

 Conocido gracias a Bruno Capuano.

martes, octubre 25, 2011

A propósito de la década de Eclipse

Jean Bezivin comparte hoy en Google+ una nota de Ian Skerrett, de la Fundación Eclipse, que puntualiza algunos de sus logros en diez años de existencia. En lo esencial:

As I have written, Eclipse is celebrating 10 years of open source and community during the month of November.   There have been a number of milestones that have shaped the Eclipse community but what have been the major accomplishments?  What has Eclipse done to actually change the software industry?  Here are what I see as some of the key accomplishments for Eclipse.
1.  Dominant Java IDE.  Eclipse started out as being a really great Java IDE and continues today to be the market leader for Java IDEs.  If you think back to the late 1990′s and early 2000′s the Java IDE market was a dog-fight between Borland JBuilder, Visual Cafe, IBM VisualAge for Java.   Eclipse is now the clear leader and has approximately 65% market share in the Java IDE market.
2. De-facto Solution for C/C++ Tools.  If you are building a tooling solution for C/C++ developers there is a very good chance you are using Eclipse CDT as the platform.   In the realtime operating system and embedded development market, Eclipse CDT has become the de-facto standard.  There at least 50 companies that are building their developer tools solution based on CDT.
3. A large and innovative modeling community.  I am not sure how to quantify it but I believe the Eclipse modeling community has grown to become one of the largest and innovative communities at Eclipse.  If you are doing modeling, chances are you are using Eclipse Modeling Framework (EMF).  However, EMF is just the core that has created a really amazing community of innovation and diversity that happens at Eclipse Modeling.   There are over 70 modeling projects at Eclipse and I know a lot more not hosted at Eclipse.   It is a great success.
4. Integrating ALM Tools.  The Mylyn project has grown into becoming the industry hub for integrating tools across the application lifecycle.   There are now over 70 different Mylyn connectors that integrate different projects into the developer desktop.
5. Modular runtimes.  Equinox and the EclipseRT projects demonstrate how modularity can work on a large scale.  Everything at Eclipse is based on Equinox, since it is the OSGi runtime.  However, Equinox and the EclipseRT top-level project has spawned an industry around Eclipse RCP and server-side OSGi.  The range of applications being built on RCP is impressive, including NASA Mars Rover, financial institutions, aircraft design, genome decoding, etc, etc.   On the server side, Equinox is used by most enterprise Java application servers and Virgo is emerging as a new Equinox based platform.
6. Eclipse Release Train.  The Eclipse release trains have demonstrated open source communities can be predictable and scale to large distributed teams.   This is incredibly important as large more conservative companies become involved in open source.  Very few other organizations can claim a track record of predictability and scale that compares to the Eclipse community.
7. Eclipse Ecosystem.  Eclipse has become one of the two major development tools platform in the industry; MS Visual Studio being the other.   No matter what language you are using there is most likely an Eclipse IDE for you.  No matter what developer tool you are using, there is probably an Eclipse plugin.   No other platform has been able to create such a diverse and large ecosystem.  It has actually made building and integrating developer tools a lot easier!
De esto algo conocemos en la comunidad de Plex: al menos dos emprendimientos vinculan extensiones de Plex con las posibilidades de Eclipse: Webclient, creando una variante web ajax a partir de la generación de código Plex java, y el trabajo de Christopher Smith, mejorando el proceso de implementación de un modelo Plex. Dos sugerencias que abren un panorama más que positivo para el futuro.

domingo, octubre 16, 2011

Una opinión sobre el valor de Java

En el curso de una discusión sobre Dart en Google+, Rafael Chaves da una interesante visión sobre Java:
"Java was not innovative at the time, and did kill many OO languages initiatives"

I am not sure Java killed other initiatives - I feel more like they were dead on arrival, at least from a market suitability PoV.

The non-technical aspects are just as important as technical merits. It does not matter how cool a language is, if it is not going to be supported by multiple vendors/platforms, if it evolves in a way that invalidates previous investments, if it is hard to learn for the average developer, if doesn't have proper support for a wide variety of application styles/domains, if is going to be hard to hire people. Getting that right is as critical as (or even more than) technical benefits.

Java got all those right, and that is why it succeeded. I don't think it is a lot about money. Sun could have poured twice as much money into it, but if they failed to recognize the importance of those aspects, it would have been a flop, or have limited success (see Microsoft .Net). But these days I wouldn't bet against similar success being attainable by an open source foundation with a strong community, without nearly the same level of financial backing, if they aimed for building for the mainstream and the long term like Sun did with Java.

As a developer, I want my investment in learning my next language to pay off for as long and across as many domains and technical architectures as possible. That is much more important than having the perfect feature set.
...y a propósito del valor de Dart, Angel "Java" López ha abierto una línea de discusión e información.

Scott Klement: juego de caracteres en el AS400

Sólo para usuarios de AS400/iSeries: Scott Klement dedica una nota suficiente al juego de caracteres y su uso al intercambiar datos con otros sistemas, y entre distintos lenguajes en el propio sistema. Necesario  de conocer. No lo voy a repetir, excepto el siguiente párrafo:

Things You Should Definitely Know

  • It is not OK to create a text string without knowing and identifying which CCSID the data is stored in.
  • It's not reasonable to expect the computer to "detect" a CCSID.
  • Power Systems (and their predecessors, System i5, iSeries, and AS/400) are not "EBCDIC machines." They can run ASCII, EBCDIC, or Unicode equally well.
  • The IBM i operating system (and its predecessors i5/OS and OS/400) do most of their work in EBCDIC, but they also understand both ASCII and Unicode and can run programs based on them (e.g., Java, PHP, PASE, Apache).
  • IBM i has knowledge of many CCSIDs (including ASCII, EBCDIC and Unicode) built in and can easily and efficiently translate between them.
  • The web is not based on ASCII. It is based on Unicode.

Things to Think About When You Have Problems

If you tell me that you have a character encoding problem, I'll want to know the following:
  • How the characters were supposed to be encoded in the original file.
  • What the CCSID of the original file was.
  • How the characters were supposed to be encoded in the destination file.
  • What the CCSID of the destination file was.
Para conservar en la guía fundamental de trabajo.

jueves, octubre 06, 2011

Estimando el impacto de Windows 8, parte II

Para comenzar, una pequeña disgresión, para hablar de un aspecto reiterado con Microsoft: la campaña anticipada sobre productos que estarán en el mercado en un futuro indeterminado pero medianamente cercano.
Lo hemos visto en tiempos más o menos próximos con Windows Vista, y en un terreno más específico, con el proyecto Oslo y todos sus elementos participantes. Este fenómeno ha producido en el pasado dos movimientos, uno razonable, de cautela y espera de parte del mercado corporativo, que se ve obligado a sopesar en cuánto le impactará una evolución del producto; o cómo deberá modificar sus estrategias, si es un proveedor de productos de Microsoft o su competidor. Y otro, no precisamente razonable, de entusiasmo y apoyo de parte de la comunidad de desarrolladores o de proveedores de servicios o productos basados en Microsoft, que por lo general, ya ante versiones tempranas del producto, aseguran que marcha más que bien, y que cura todos los males del mundo, en los casos más extremos de adhesión a la marca. De tal forma que comienza a producirse una espiral de información y debate sobre algo que está a mitad de desarrollo, cuyas características podrán variar, o incluso podrá ser discontinuado como vía de investigación, con entusiastas que son capaces de describir un algoritmo que seguramente funcionará en el futuro. Los casos de Longhorn (Vista) y Oslo muestran particularmente estas características, y sus consecuencias. Esto produce, a mi juicio, dos efectos negativos importantes: condiciona o aplaza las decisiones y estrategias de quienes están relacionados y dependientes del ecosistema de Microsoft, y produce descrédito en la marca por el largo proceso de maduración del nuevo producto, sujeto a la exposición pública cuando todavía no está acabado. Y mucho mayor descrédito si toda esa "burbuja" de información conduce a un producto discontinuado.
Este comienza a ser el caso de Windows 8: es sorprendente el número de rápidas conclusiones sobre el producto que se pueden encontrar en éstos días. Pronto veremos condicionar muchos proyectos basados en lo que vendrá, que  también pudiera ser lo que vendría. Nuevamente, proliferan las afirmaciones basadas en un kit de demostración que no maneja todas las variables, porque los planes de desarrollo ni siquiera tienen fechas públicas de entrega.
Finalmente, desde el punto de vista del usuario, especialmente del usuario corporativo, que es esencialmente distinto del que compra en el mercado general, existe una pregunta: ¿me hace falta pasar a Metro? ¿necesito en mis cien/quinientos/mil escritorios de mi casa central disponer de terminales táctiles? Sin embargo, cualquiera sea la respuesta, probablemente el resultado final será que seré condicionado a adoptar el nuevo paradigma, y deberé replanear mi arquitectura. Al menos, si Windows es mi terminal cliente.
Lo que me lleva a lo que quería recordar hoy: una pequeña nota sobre la actualización contínua del software que Kevin Kelly escribió en abril:

(...) It's taken me 60 years, but I had an ephipany recently: Everything, without exception, requires additional energy and order to maintain itself. Not just living things, but the most inanimate things we know of: stone gravemarkers, iron columns, copper pipes, gravel roads, a piece of paper. None will last very long without attention and fixing, and the loan of additional order. Life is maintenance.
Most surprising to me has been the amount of sheer maintenance that software requires. Keeping a website or a software program afloat is like keep a yacht afloat. It is a black hole for attention. I can kind of understand why a mechanical device would break down after a while -- moisture rusts metal, or the air oxidizes membranes, or lubricants evaporate -- all of which require repair. But I wasn't thinking that the intangible world of bits would also degrade. What's to break? Apparently everything.
Here is news to the young: Crap accumulates in code. Chips weaken. Programs break. On their own, nothing you did.
And then there is the assault of the changing digital landscape. When everything around you is upgrading, trying new actions, or seeking new loopholes, this puts pressure on the website and necessitates maintenance. You may not want to upgrade, but you have to because everyone else is.
This upgrade arms race spills over into our private lives. It's completely altered my attitude about upgrading. I used to upgrade begrudgingly (why upgrade if it still works?), and at the last possible moment. The trouble is familiar. Upgrade this and suddenly you need to upgrade that, which triggers upgrades everywhere. A "tiny" upgrade of even a minor part can be hugely disruptive. But as our personal technology became more complex, more co-dependent, more like a personal ecosystem, delaying upgrading is even more disruptive. So I now see upgrading as a type of maintenance: you do it to survive. Technological life in the future will be a series of endless upgrades.
Expecting to spend your life upgrading should be a life skill taught in school. Indeed, I'd like to learn how to manage maintaining my digital ecosystem better myself. There must be a zen and art to upgrading.


domingo, octubre 02, 2011

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.

martes, septiembre 13, 2011

languidece .NET?

Se multiplican los avisos de cambio de paradigma en Microsoft. Si hace algún tiempo los usuarios de Silverlight encendían luces de alarma, ahora creo que toda la comunidad de desarrolladores con algún contacto con Microsoft debe ajustar sus cinturones...Windows 8 anuncia cambios de fondo, dejando casi como "legacy" el concepto de aplicaciones de escritorio, adoptando un estilo basado en las nuevas características de recursos móviles (tabletas y teléfonos). Cambios extensos, radicales, que abarcan el API Win32 mismo. ¿Es la ruptura constante un criterio razonable para abordar el mercado?
Jonathan Allen, en InfoQ, publica un panorama de los cambios que [parece que] se avecinan :

Windows 8 introduces a new core API called WinRT. This is used to develop Metro style applications using C/C++, .NET, or JavaScript. These applications automatically gain features such as hardware acceleration and advanced power management out of the box. Existing Silverlight and WPF applications can be ported to the new “Native XAML” libraries with minimal effort.
What follows is a summary of the keynote presentation. More details will be provided as they become available.
General Notes
Windows 8: Base line memory usage dropped from 540 MB to 281 MB.
The lock-screen can now display user content.
Touch-based passwords, essentially you tap on three points of an image to unlock the machine.
Like Windows Phone, the start page uses the metro style with live tiles.
There is a heavy emphasis on full screen applications.
Application specific and system settings share the same space on the user interface. It appears that applications will need to indicate which systems settings are relevant.
New version of Internet Explorer will be completely free of chrome. All of that functionality is hidden in application bars that slide into view.
Spell check is included system wide.
Developer preview includes Visual Studio 11 Express, Expression Blend 5. There is no timeline for the next milestone, which is the public Beta. Intern updates will be pushed to the preview machines on an as needed basis. The preview will be available starting tonight as http://dev.windows.com at for x86/x64.
Application Integration
Windows 8 will have extension points known as “charms”. An example of a charm is the “share charm” which shows all the ways text can be shared such as email, Facebook, Twitter, etc. Applications can register themselves inside a charm by implementing the correct interfaces. Meanwhile other applications can indicate they are capable of sending information to the charm. The concept is very much like JavaScript mashups or classic OLE, but with a lot more thought about what those interactions should be.
System wide search is now supported. Again, applications can register themselves as a search provider.
Applications can expose files directly from the cloud for use by other applications. One does not need to copy files such as images to the local hard drive before other applications can access them.
Developing for Windows 7: Classic platforms:
· HTML/JavaScript on Internet Explorer
· C/C++ on Win32
· C#/VB on .NET and Silverlight
Developing for Windows 8: Metro Style
Windows Kernel is still at the bottom of the stack
WinRT is the new OS-level API layer. This is the new native API for Windows, it isn’t a new layer on top of Win32.
You can access WInRT from C/C++, C#/VB, or JavaScript. XAML is the UI layer for C, C++, C#, and Visual Basic. HTML/CSS will continue to be used as the UI layer for JavaScript.
Visual Studio will have project templates for the various styles of Windows 8 applications. The first demonstration is a JavaScript-based application. The application isn’t compiled but it is packaged into a bundle that includes all the html and JavaScript files needed by it. Windows 8 runs it directly, there is no need to launch the web browser.
As alluded to above, JavaScript can access the native functionality from the WinRT API. In the keynote demo it only took a couple lines of code to expose the new Windows open file dialog. Since Facebook was already installed on the machine the open file dialog showed images from the presenter’s Facebook page. The JavaScript application had no networking code at all, this link between it and Facebook was handled entirely by the platform.
Expression Blend now supports HTML and CSS with much
The HTML 5 grid proposal is essential to building Windows 8 applications. Without it supporting the wide variety of screen resolutions that Windows 8 runs on would be very difficult.
Metro style applications are automatically suspended when not visible. This was done to prolong battery life.
App Stores
As expected there is now going to be a Windows store for distributing applications. The technological aspects of application licensing is handled by the by store itself, one merely has to indicate basic information such as price and whether or not there is a demo period.
A certification process is required for offering applications in the Windows store. The tools used to certify applications will be given to developers so they can see and correct violations before they formally submit the application.
The application for accessing the Windows 8 store is actually written using JavaScript over the WinRT API.
The app store is not limited to Metro style applications, traditional Win32 applications can also be offered via the store.
Upgrading from Silverlight to Windows 8
In the demo all the of the existing XAML worked as-is. The presenter just needed to change the namespaces (e.g. System.Windows becomes Windows.UI) and tweak the networking code. With only a couple more lines of code he was able to register the application as a search provider.
Moving from Windows 8 to Windows phone just required an extra line or two.
Hardware Support
A new mode called “Connected Standby” is inspired by mobile devices. The power consumption is very low with occasional spikes as the Windows temporarily turns on the network connection to allow applications to receive updates. Since the system is never actually turned off it comes alive instantly.
Max hard drive size is 256 terabytes. Windows 7 was limited to a 2 terabyte boot drive.
The entire platform is built to use hardware accelerated graphics. Metro style applications will use them by default, no additional coding is needed to enable it.
The Sensor Fusion API will combine the information from the gyro, accelerometer, and magnetometer. Getting basic information such as the physical orientation of the device takes three lines of code.
The networking stack now supports concepts such as the side-channels in 3G.
For the give-away they are offering a Tablet running Windows 8 and Visual Studio.
Refresh and Reset
Using the Refresh command will remove everything except personal information/settings. Metro-style applications will be retained, any Win32 style application will be removed. This is one from a baseline image and should be run in response to system problems such as viruses.
The Reset command will completely wipe the PC. All personal information is removed and it is returned to the factory settings as if it were just purchased new.
There is a command line tool to update the baseline image. This would be used to add applications such as Visual Studio or Office to the standard image. Enterprise users would most likely want their companies custom software also included in this baseline image.
Cloud Services
Application settings, themes, passwords, etc. can by synchronized across machines using a Windows Live account.
The Windows address book pulls in contacts from all sources including social networking sites and exposes them via your Windows Live account. Likewise shared calendars are aggregated.
Windows SkyDrive is available to all users with a Windows Live account. Developers can access it as if it were a normal disk drive.
Windows Live allows one machine to access another even if it is behind a firewall. Companies that are concerned about information security should take care, as this allows common users with no technical skills easily move otherwise restricted files from their workstation to home machine without even being in the building.
Microsoft is expecting developers to use Windows Live to connect their applications together.
Who built the Apps?
17 teams of 2 to 3 developers each worked for ten weeks on the demo applications. They were all summer interns working on an evolving platform.
Fasten your belts, gentlemen...

jueves, agosto 25, 2011

ERPs e innovación (a propósito de gerenciamiento)

Adam Hartung, comentarista de tecnología de Forbes, compara la dirección de Hewlett Packard con la de Apple, señalando el gerenciamiento "de corte industrial" de HP como gran causa de su progresivo deterioro. Pero hablando de gerenciamiento e innovación, Hartung da una agresiva e interesante visión del software ERP.  Qué dice Hartung:

Now CEO Apotheker’s plan for HP’s growth is selling ERP software from a third-tier competitor. ERP (enterprise resource planning) applications like SAP and Oracle are viewed today as the remarkably expensive, hard to install, hard to maintain, hard to modify, monolithic, bureaucracy creating, innovation killing systems they were designed to be.  ERP applications were created to force companies, functions and employees to replicate previous decisions, in the hopes of increasing control (especially financial control) and cutting operating cost.  Not to learn, or do anything new.  They were designed to create rigidity, and are completely unable to enhance flexibility, market responsiveness and growth.  ERP was the emerging high-tech “solution” in 1992!
It is clear Mr. Apotheker is returning to his previous personal success, as CEO of SAP.  He isn’t looking to the future and how he can meet new, unmet needs.  He’s investing in what he knows, from his past.  His focus on “business solutions” is his way of pushing HP to be more like SAP – only 2 decades too late, against enormously well funded competitors, in a low-growth marketplace looking for new solutions.  Too bad for HPs investors, employees and suppliers.

domingo, agosto 21, 2011

IBM como parte de la historia tecnológica

Un artículo aquí que suele ser visitado es el que habla sobre la historia de los servidores de IBM. Lamentablemente, el enlace que abre el artículo hace mucho tiempo que dejó de apuntar a algo, viejo problema de cualquier artículo apoyado en la web...A raíz de éste y otros casos similares, hace tiempo que reemplazo los enlaces por un extracto del tema de que se trate. No pierdo la esperanza de recuperar el viejo artículo, pero algo se puede hacer: gracias a The wayback machine, se puede recuperar un corte de la página al 5 de enero de 2007, que refleja en general el contenido de aquella página. Esta referencia se incluye ahora en mi nota de 2006. Dada la volatilidad del material escrito para Internet, The Internet Machine cumple un servicio irreemplazable.
Pero volviendo a IBM y su influencia en el desarrollo tecnológico del siglo XX: a raíz de su centenario, la empresa ha desarrollado mucha documentación que supongo que será más persistente. El conjunto más importante de documentos, es el que enumera cien aportes de IBM a la tecnología. Lamentablemente, por falta de tiempo dejé pasar el mejor momento para reproducir excelentes materiales difundidos durante el centenario. No obstante, este resumen y otros posteriores se proponen remediarlo. Y respecto a IBM, la observación más destacada acerca de su centenario, no es tanto acerca de su capacidad de crecer y mantenerse en la primera línea de la investigación tecnológica, sino la pregunta sobre su futuro: hace ya algunos años IBM ha producido un giro radical en su visión de los negocios, que por ahora da buenos dividendos, pero pone en cuestión su liderazgo tecnológico, y su esfuerzo en el desarrollo de la investigación. La pregunta es ¿tendrá un segundo siglo de liderazgo?

Volviendo a los papeles del centenario: puestos en desorden, simplemente por preferencias y a medida que los voy encontrando, el primero para reproducir es el dedicado a Codd y las bases de datos relacionales:
In 1970, Edgar F. Codd, an Oxford-educated mathematician working at the IBM San Jose Research Lab, published a paper showing how information stored in large databases could be accessed without knowing how the information was structured or where it resided in the database.
Until then, retrieving information required relatively sophisticated computer knowledge, or even the services of specialists who knew how to write programs to fetch specific information—a time-consuming and expensive task.
Databases that were used to retrieve the same information over and over, and in a predictable way—such as a bill of materials for manufacturing—were well established at the time. What Codd did was open the door to a new world of data independence. Users wouldn’t have to be specialists, nor would they need to know where the information was or how the computer retrieved it. They could now concentrate more on their businesses and less on their computers.
Codd called his paper, “A Relational Model of Data for Large Shared Data Banks.” Computer scientists called it a “revolutionary idea.”
Today, the ease and flexibility of relational databases have made them the predominant choice for financial records, manufacturing and logistical information, and personnel data. Most routine data transactions—accessing bank accounts, using credit cards, trading stocks, making travel reservations, buying things online—all use structures based on relational database theory.
Codd’s idea spawned a new family of products for IBM, centered on the IBM ® DB2 ® database management system, as well as the industry-standard computer language for working with relational databases, called SQL.
According to the New York Times obituary for Codd, “… before Dr. Codd’s work found its way into commercial products, electronic databases were ‘completely ad hoc and higgledy-piggledy,’ said Chris Date, a relational data expert who worked on DB2 at IBM before becoming a business partner of Dr. Codd’s.”
Like many revolutionary ideas, the relational database didn’t come about easily.
By the 1960s, the vast amount of data stored in the world’s new mainframe computers—many of them IBM System/360 machines—had become a problem. Mainframe computations were expensive, often costing hundreds of US dollars per minute. A significant part of that cost was the complexity surrounding database management.
Codd, who had added a doctorate in computer science to his math background when he came to the United States from his native England, set out to solve this problem. He started with an elegantly simple premise: He wanted to be able to ask the computer for information, and then let the computer figure out where and how the information is stored and how to retrieve it.
IBM’s Don Chamberlin said that Codd’s “basic idea was that relationships between data items should be based on the item’s values, and not on separately specified linking or nesting. This notion greatly simplified the specification of queries and allowed unprecedented flexibility to exploit existing data sets in new ways.”
In his seminal paper, Codd wrote that he used the term relation in the mathematical sense of set theory, as in the relation between groups of sets. In plain terms, his relational database solution provided a level of data independence that allowed users to access information without having to master details of the physical structure of a database.
As exciting as the theory was to the technical community, it was still a theory. It needed to be thoroughly tested to see if and how it worked. For several years, IBM elected to continue promoting its established hierarchical database system, IBM IMS (Information Management System). A hierarchical system uses a tree-like structure for the data tables. While IMS can be faster than DB2 for common tasks, it may require more programming effort to design and maintain it for non-primary duties. Relational databases have proven superior in cases where the requests change frequently or require a variety of viewpoint “angles.”
IBM, Rockwell and Caterpillar developed IMS in 1966 to help track the millions of parts and materials used in NASA’s Apollo Space Program. It continues to be IBM’s premier hierarchical database management system.
In 1973, the San Jose Research Laboratory—now Almaden Research Center—began a program called System R (R for relational) to prove the relational theory with what it called “an industrial-strength implementation.” The project produced an extraordinary output of inventions that became the foundation for IBM’s success with relational databases.
Don Chamberlin and Ray Boyce invented SQL, for Structured Query Language, today the most widely used computer language for querying relational databases. Patricia Selinger developed a cost-based optimizer, which makes working with relational databases more cost-effective and efficient. And Raymond Lorie invented a compiler that saves database query plans for future use.
In 1983, IBM introduced the DB2 family of relational databases, so named because it was IBM’s second family of database management software. Today, DB2 databases handle billions of transactions every day. It is one of IBM’s most successful software products. According to Arvind Krishna, general manager of IBM Information Management, DB2 continues to be a leader in innovative relational database software.
Dr. Codd, known as “Ted” to his colleagues, was honored as an IBM Fellow in 1976, and in 1981, the Association for Computing Machinery gave him the Turing Award for contributions of major importance to the field of computing. The Turing is generally recognized as the Nobel Prize of computing.

Selected team members who contributed to this Icon of Progress:

  • Ray Boyce Co-developer of SQL (Structured Query Language)
  • Edgar “Ted” Codd Mathematician, IBM Fellow
  • Donald Chamberlin Co-developer of SQL
  • Christopher J. Date Longtime collaborator of Ted Codd
  • Patricia G. Selinger Founding manager of the Database Technology Institute at IBM Almaden Research Center
Los enlaces del artículo reproducido son míos.

sábado, agosto 20, 2011

SPLC 2011

Con programa preliminar a partir de este domingo, el lunes y martes próximo se desarrollará en Munich la 15ª conferencia de Lineas de Producto Software (SPL, Software Product Lines). Un concepto fundamental en la construcción de software, una fuente de ideas para quienes lo construyen, tanto sea en grandes unidades económicas, donde sus conceptos deberían ser  irremplazables, como para unidades menores, donde deberían motivar líneas de investigación y trabajo más racionales.
Aunque hemos conversado más de una vez sobre su significado, la descripción de uno de sus tutoriales explica razonablemente su meta:
Product Line Engineering is a common approach to address a business with a family of related software products. Instead of having separated development projects for each product in the family, products are built using a shared set of core assets, such as reference architectures and common infrastructure and domain-specific components. Key drivers for PLE are the potential cost savings due to shared core assets, as well as new business opportunities by, for instance, supporting tight integration and improved interworking among members of the product family. 
 Estoy persuadido de que SPL y MDD recorren caminos convergentes y retroalimentados. Uno de los tutoriales que se desarrollarán, toca esta característica: "Leveraging Model Driven Engineering in Software Product Lines", desarrollado por  Bruce Trask and Angel Roman:
Model Driven Engineering (MDE) is a promising recent innovation in the software industry that has proven to work synergistically with Software Product Line Architectures (SPLA). It can provide the tools necessary to fully harness the power of Software Product Lines. The major players in the software industry including commercial companies such as IBM, Microsoft, standards bodies including the Object Management Group and leading Universities such as the ISIS group at Vanderbilt University are embracing this MDE/SPLA combination fully. IBM is spearheading the Eclipse Foundation including its MDE tools like the Eclipse Modeling Framework (EMF) and the Graphical Modeling Framework. Microsoft has also launched their Software Factories and DSL Toolkit into the MDE space. Top software groups such as the ISIS group at Vanderbilt are using these MDE techniques in combination with SPLAs for very complex systems. The Object Management Group is working on standardizing the various facets of MDE. All of these groups are capitalizing on the perfect storm of critical innovations today that allow such an approach to finally be viable. To further emphasize the timeliness of this technology is the complexity ceiling the software industry find itself facing wherein the platform technologies have increased far in advance of the language tools necessary to deal with them. This complexity ceiling is evident in today’s Software Product Lines.
 Invito a seguir sus sesiones, a solicitar sus presentaciones, y a tomar contacto con sus participantes. Estas conferencias anuales acercan el mejor material sobre el tema.

Información y seguimiento en el sitio de la conferencia.

jueves, agosto 04, 2011

Actualización en comunicaciones

A propósito de la introducción oficial del sistema de TDT en España (el asunto sería válido también en Argentina y Chile, con cambios recientes en el mismo sentido), la compañia de satélites Astra maneja un informe que lo cuestiona, y que pone sobre la mesa el estado del uso de las comunicaciones. D. Toledo, en El Confidencial:

“La sentencia definitiva a la TDT nace en la propia Comisión Europea, que contempla como escenario la liberalización total del espectro radioeléctrico para dedicarlo a otros servicios, con lo que la televisión se difundiría mediante otras tecnologías. En definitiva, hablaríamos de la total desaparición de la TDT”, reza el informe. Astra recuerda que la televisión digital terrestre restringe el espacio de que disponen los operadores para sus emisiones, lo que limitará el desarrollo de los programas en alta definición o en 3D. “Tendrán que elegir y descartar los componentes vanguardistas. El satélite, el cable o Internet son el futuro de la televisión, por mucho que el Gobierno español haya hecho una muy equivocada y costosa apuesta”, remata.
La cruzada de Astra contra la TDT es de largo aliento. Y no es del todo inocente. Se siente perjudicado por el modelo elegido por el Gobierno, ya que atentaría contra el principio de neutralidad entre tecnologías. Según calcula la empresa luxemburguesa, llevar la señal de televisión digital terrestre a entre el 96% y el 98,5% de la población ha supuesto la creación de 3.750 centros de radiodifusión nuevos, lo que implica una inversión inicial de 327 millones de euros, con un coste de mantenimiento de 67,2 millones anuales. De acuerdo con sus estimaciones, el satélite es más eficiente a partir de un 90% de cobertura. 
La progresiva liberalización del espacio radioeléctrico para generar el denominado dividendo digital y dar cabida a servicios de banda ancha móvil a velocidades superiores a las actuales refuerza estos argumentos. De momento, el proceso obligará a reubicar las cadenas. Ya está en marcha la modificación de los canales instalados en la banda entre los 790 y los 862 MHz. “Los operadores, conscientes de que el futuro pasa por la transmisión de datos mediante la red móvil, ya han anunciado que necesitarán más espacio (al menos 100 MHz), con lo que se prevé que un segundo dividendo digital, previsto para 2015, se adelante a 2013”, añade Astra. Cada cambio de esta índole obliga a los hogares a una nueva antenización.

miércoles, julio 27, 2011

Patentes, innovación, y el perro del hortelano...

Quiero reproducir la nota de Mariano Amartino sobre el problema de las patentes en Estados Unidos, modelo que comienza a proliferar bajo diversas formas en otros lugares...Un modelo que se asemeja a otro caducado hace doscientos años...
Las patentes de software en USA ya paralizan emprendedores
Interesante artículo de The Guardian: App developers withdraw from US as patent fears reach ‘tipping point donde se muestra que para un desarrollador independiente ya es casi imposible desarrollar una nueva aplicación de software sin estar pisando o rozando una patente propiedad de algun gigante o de un troll de patentes.
Recuerdo haber escrito irónicamente como Intellectual Ventures era “La fábrica del futuro” y como su modelo era sentarse a imaginar cosas y patentarlas sin intención de usarlas… solo tenerlas en un portfolio capaz de ser usado para atacar legalmente a los que crearan productos relacionados.
Pero tal vez, lo que nunca imaginé era que en algún momento esto iba a molestar tanto al ecosistema de emprendedores que en medio de demandas cruzadas se iba a obligar a IV a mostrar el nombre de sus inversores y algunas sopresas aparecen en ese listado: Apple, Microsoft, Amazon, American Express, Cisco, eBay, Google, Intel, Nokia, Sony… y al menos una docena de universidades están apoyando este modelo de la forma más explícita posible: con cash puro y duro. [Listado completo de inversores en este PDF]
Y entonces lo que uno ve es que el famoso mantra de fomentar la innovación que muchos dicen es una simple mentira ¿como se va a fomentar la innovación si ponen fondos en la expresión máxima de un Patent Troll? ¿como van estas empresas a “foster the entrepreneurship” cuando están cerrando caminos a innovadores para patentar ideas con el fin último de tenerlas dormidas y demandar a terceros? Eso no es innovación y eso muestra que el Gobierno de USA (en momentos que busca hasta tener Visas para Emprendedores) no entiende el nivel de estancamiento que tiene su modelo económico.
Coincido con Chris Sacca cuando dice que este es un modelo mafioso que recién ahora se empieza a hacer conocido… de hecho para el que no lo sabía la gente de Intellectual Ventures tiene 1100 sociedades anónimas CREADAS para demandar a emprendedores.
Lo perverso en esto que las patentes de software (y otras) nacieron para darle al pequeño inventor la posibilidad de tener una ventaja intelectual frente a los gigantes que los copiaban y solo hubo dos cambios en el proceso de patentamiento que lo convirtieron en un modelo anti-innovación:
a) Los tiempos se hacen lo más largo posibles al punto de ser ridículos
b) No se exige una aplicación real para aprobarlo ni se revisa el arte previo
Para poner un ejemplo, si tengo una persona sentada en un escritorio y piensa: “mmmm en el futuro se va a poder manejar una interfaz de usuario sin tocar una pantalla o un dispositivo físico, la orientación de nuestra mirada va a servir para ejecutar comandos” y si Julio Verne hubiera ido a la oficina de patentes de USA hoy la aviónica de Lockheed-Martin para los F22 no se podría aplicar porque:
a) Esa patente era perpetua
b) La tecnología necesaria para que ESE pedazo de innovación aparezca recién estuvo disponible hace poco
Cuando la idea de negocio es sentarse e imaginar el futuro (sin saber como funciona) patentarlo y esperar que otros creen los bloques que pueden hacer esas patentes una realidad para ir a demandar por millones de dólares a cualquiera que quiera emprender o crear algo nuevo… es que el sistema está podrido.
Duda: ¿te parece que exagero? Lean sobre France Brevets o miren Patent Absurdity

sábado, julio 16, 2011

LeanEssays: How Cadence Determines Process

Leído en el blog de Mary Poppendieck...

LeanEssays: How Cadence Determines Process: "If you want to learn a lot about a software development organization very quickly, there are a few simple questions you might ask. You might..."

jueves, julio 14, 2011

Webclient mobile es ahora open source

La newletter de CM First publicada hoy comunica que la elaboración de las nuevas plantillas destinadas al soporte de aplicaciones móviles se convierte en un proyecto open source. Es decir, abierta fundamentalmente a la comunidad de usuarios y desarrolladores de Plex/Webclient, porque de todas formas trabajar con ellas exige disponer de una licencia. Sin embargo, esta decisión representa otro paso destinado a abrir el desarrollo de patrones, semejante al que diera AllAbout hace un par de años abriendo el desarrollo de su desarrollo sobre XML. La arquitectura de Plex en su basamento en patrones y el desarrollo creciente de su API están permitiendo abrir sus posibilidades y extender su alcance. Los patrones para dispositivos móviles (teléfonos y tablets) se han iniciado con una base importante, y se potenciarán con participación abierta. Hay muchos otros campos donde aplicar este concepto.
El nuevo proyecto, en Google.Code.

domingo, julio 03, 2011

Sugerencias que da un proyecto

Bob Fields, de Walt Disney World, comenta en The Model Driven Software Network, la  estrategia de la compañía para el desarrollo de sus aplicaciones usando Java, Eclipse, Rational, Maven. Una experiencia que recién comienza a describir, pero que ya presenta aspectos de interés si la sobrevolamos un poco, sea en general como medio de articular una línea de trabajo con MDD, o, siendo más específico, desde el punto de vista de Plex. Dice Bob:
(...) My main passion as an architect is in finding ways to improve the software development process through automation. I have championed the adoption of Apache Maven at WDPR, but much work remains before we have full adoption and integration over all phases of the lifecycle.(...) I led the effort to adopt an MDA tool several years ago. After investigating a number of alternatives (two no longer exist: OptimalJ and ArcStyler), we settled on the open source tool AndroMDA because of the maven implementation plus the mature output capabilities using velocity templates: Java, Spring, Hibernate, EJB, EJB3/JPA, Struts, JSF, WebServices, jBPM/Drools, dotNet NSpring/NHibernate/ASP.
 Es decir, articular una herramienta MDD con el mayor espectro posible de salidas, incluyendo todo en algún tipo de herramientas que permita articular y automatizar cuanto sea posible del ciclo de vida del sofware. En el caso de Plex, muchas sugerencias para extender y abrir el desarrollo, adelantándose a lo que en un momento determinado sea posible hacer con la IDE. Lo que iniciara Webclient (puente con Eclipse + Web), ampliado.

jueves, junio 23, 2011

Win8, Silverlight, y otra razón en favor de MDD

Las primeras presentaciones de Windows 8, todavía muy preliminares, han contribuído a crear un revuelo mayúsculo en al menos parte del mundo de desarrolladores de Microsoft, básicamente en la comunidad de Silverlight, y hasta cierto punto también en la comunidad .NET. Según parece (a casi dos años todavía de su lanzamiento), Windows 8 será profundamente distinto, tanto en su diálogo con el usuario, como en las herramientas con las que construirá su interfaz con él. La respuesta pública ha tenido dos caras: de parte del mercado comprador (hogar y socios de negocios interesados en salir al paso de la competencia en tablets y teléfonos inteligentes), expectativas positivas. De parte de la comunidad de socios y desarrolladores que construyen para su arquitectura actual, quejas y desconfianza. ¿Por qué? porque intuyen, tanto a través de las presentaciones, como por lo que no se dice, que las herramientas actuales ya no estarán en el centro del negocio, sino que pueden caer a un mercado secundario, mientras el foco se desplaza a aplicaciones montadas sobre HTML5, CSS3 y javascript. Justin James, en Techrepublic, es uno entre otros muchos, que describen este estado:

There is an absolute firestorm around HTML5-based apps in Windows 8 and where it leaves native app technologies like WPF, Silverlight, and WinForms. I have no idea what is happening for sure, and I guarantee you that all of my Microsoft contacts either do not know or would not tell me if they did, and I respect that. Here is what I do know:
  • Windows 8 appears to have an application building engine based on HTML5 technologies (I’m including JavaScript and CSS3 in that umbrella).
  • Microsoft stopped pushing Silverlight as a Web app add-in a while ago, and said it was for “out of browser,” cross-platform, and special purposes (like WP7 development).
  • WinForms got backburnered with the release of WPF.
  • The pace of Silverlight development has slowed significantly as the technology matures.
  • Silverlight has been a big success in writing internal applications, and Silverlight is not the pain point in writing WP7 apps (the APIs and their lack of support for many scenarios are).
  • Microsoft has displayed a worrisome habit of dropping technologies just as they seem to be fulfilling their potential.
  • Silverlight has been increasing its capability for quite some time, heading towards convergence with WPF. The big barrier has been the size of the download; the Silverlight team stated a while back that the installer should never be bigger than Flash’s.
Based on what I know and the current trends, I do not think Silverlight is going away any time soon, but I do think Microsoft is seeing HTML5 as “Silverlight Lite.” Since Silverlight is already “WPF Lite,” It’s conceivable that WPF and Silverlight will merge, basically putting the out-of-browser capability onto WPF, and either taking out the stuff that doesn’t go across platforms or just having two WPF profiles (just as Silverlight has a phone profile that is less capable than the full Silverlight platform). Then, Microsoft can feel free to push its HTML5 apps to folks that like the Silverlight idea but don’t feel comfortable with the technology. This is 100% pure conjecture on my part though. Mary Jo Foley has some interesting information as well, and Laila Lotfi has a good analysis of the situation.
Pongamos esta situación entre paréntesis: falta mucho para que se desenvuelva completamente la ¿nueva? estrategia de Microsoft. En poco más de dos años, se ha producido una explosión de ofertas de arquitecturas, sistemas operativos, y estilos y alcance de aplicaciones. Claramente esta situación clama por otro estilo de desarrollo. Jugarse hoy por una arquitectura puede ser suicida, pero no dedicarse a ella también puede ser una decisión para arrepentirse largamente. Este panorama trae a primer plano a las herramientas que basan el desarrollo en modelos, construyendo la lógica de negocios, o la lógica a secas, en un terreno abstracto, con la capacidad de desplegarla luego en la arquitectura que haga falta. Así, si una arquitectura de pronto va a vía muerta (como quizá pase con Simbian), el patrimonio en aplicaciones desarrolladas no queda atada a la arquitectura, la plataforma, o el framework, sino que es viable desplegarlo en otra alternativa.
Frente a las ocasionales afirmaciones acerca de eventuales debilidades del desarrollo basado en modelos, me cuento entre quienes sostienen que este universo de múltiples galaxias, tiene su llave en MDD. Cuando he presenciado defensas de distintos frameworks, en un momento donde éstos se encuentran en general atados a un puñado de propietarios, he sostenido que jugarse por uno puede significar perder mucho, simplemente si el propietario es comprado o cambia de estrategia (y está claro que Simbian no es el único caso).
El carácter abierto de MDD permite que un ecosistema de herramientas de modelado se acompañe por otro que permita ofrecer generadores que transformen los modelos abstractos a las distintas arquitecturas, plataformas, frameworks y lenguajes. Si el estado hoy es imperfecto, hacia allí se moverá, perfeccionando las soluciones.

jueves, junio 16, 2011

Conferencia CGN: Karsten Thoms sobre principios básicos

A falta de oportunidad de participar en la conferencia, dedicaré algunos días a comentar lo que de las presentaciones aparece como más interesante. Soy enemigo de los powerpoints, porque están pensados para servir de guía durante una conferencia o presentación, y acompañan la conversación del disertante, pero reflejan pálidamente lo que el autor conversó. En el caso de la presentación de Karsten Thoms, esta es tan espartana que podría dudarse de cuál fue su contenido. Sin embargo, los diez títulos hablan fuerte y claro. De entre ellos, quiero destacar los siguientes, que coincido en que determinan la factibilidad de usar un generador de código. Interpretaré libremente lo que Karsten explicara, basándome en sus sentencias minimalistas:

Mezclar artefactos cuyo código es generado con otros creados 'a mano' (Mixed Generated/Manual Code Artifacts). Este escenario implica que hay aspectos que, aunque fueran representables en un modelo, no pueden ser traducidos a código. Estos espacios no cubiertos derivan de un generador que ignora aspectos del modelo, y por lo tanto no es capaz de representar la totalidad. Aún cuando pudiera haber casos en que la parte manual (opaca para el modelo) pueda rescatarse, al no tener relación con la descripción abstracta, el esfuerzo de integración corre por cuenta del "codificador manual". Si aplicamos esta falta de integración a modelos complejos y grandes, el esfuerzo de seguimiento de la relación entre las dos partes es peligroso, y posiblemente motivo de fracaso.

No reestructure su código generado (Don‘t Refactor Your Code Generator Code). Aplicar una nueva capa de optimización de código al código generado es doble trabajo, y ganancia de corto alcance, ya que al no afectar al modelo, el código se reproducirá a la siguiente oportunidad. Si su ciclo de desarrollo se basa en iteraciones cortas, la refactorización puede ser agotadora (e inútil a futuro). Esto no quiere decir que no sea bueno refactorizar. Pero debe hacerse sobre el modelo, y sobre las reglas de transformación; es decir, una refactorización bien distinta. El código debe derivar optimizado, no rehecho a posteriori.

Hay otros tres puntos que resultan especialmente interesantes, pero en este caso, trataré de conocer directamente su posición sobre ellos:
  • Missing Reference Models /Implementations
  • Don‘t Participate Developers
  • Requiring The IDE For Execution
 Para seguir a Karsten, su blog.