Mientras Plex 7.2 continúa en beta, y nuevos cambios de arquitectura aparecen en el horizonte, me interesaría retomar una conversación iniciada en mayo: qué hacer con la variante c++ (WinC) de Plex. Como se mencionara entonces, existe una iniciativa expuesta por Simon Cockayne, product manager, por actualizar el soporte de Visual Studio de 2005 (qué horror!) a Visual Studio 2012 "o el más reciente que exista". Algo más que necesario...Pero a partir de este punto, existen diferentes líneas de avance. Dos o tres ideas sobre esto:
Algunas respuestas sugieren pasar entonces directamente a una variante .NET, esto sería, dado que la línea principal de trabajo en CA Plex parece apoyarse en .NET, evolucionemos a ella. Pero esto presenta tres escollos, a primera vista: Uno, económico, ya que no se trata simplemente de reconfigurar el modelo para adoptar una nueva variante (cambiar el valor de un combo box en la ventana de configuración), sino de pagar nuevas licencias, una por cada asiento que vaya a trabajar generando en la nueva configuración. Aunque existan ofertas o paquetes de negociación, es un costo que hay que pesar.
Un segundo escollo de importancia es la migración: no se trata tan solo de migrar paneles, sino de inventariar el conjunto de APIs de bajo nivel que se hayan estado utilizando basadas en c++/win32, y probablemente reescribirlas. Se trata de tener en cuenta la diferencia de modelo de arquitectura (managed/unmanaged code; framework de .NET). Todos los interesados, (y aquí se debería incluír también al soporte de CA) deben pesar el impacto de migrar no solo el código evidente, sino también cualquier dependencia de ActiveX, OLE, COM y VBScript. Todo ha sido afectado por el modelo .NET.
Y el tercer escollo a tener en cuenta es .NET en sí mismo: este parece ser un buen momento de la arquitectura, considerando los planes para abrirla a la comunidad en general. Pero atendiendo a los adelantos informados, no está claro que la apertura sea suficiente ni exenta de nuevas contradicciones. Este es un tema que requiere ser tratado por separado. Pero además, tampoco está claro qué papel tendrá finalmente .NET en los planes futuros de Microsoft, considerando su evolución a la nube, y los cambios de arquitectura desarrollados a partir de Windows RT.
Entretanto, no sólo evoluciona la arquitectura de Windows en general, sino también Visual Studio y el propio c++, tanto el estándar en sí mismo como la interpretación de Microsoft: hoy c++ 11, con planes para c++ 17. ¿Cómo de integrados están los planes en curso? Considerando la experiencia pasada, me pregunto, con pocas esperanzas de que se pueda tomar un curso preventivo, si no hubiera sido estratégicamente preferible, largo tiempo atrás, mantener un núcleo del generador mas apoyado en el estándar y algo distanciado de los planes de desarrollo de Microsoft. La variante de Plex es WinC, e implica un compromiso con Windows ya en su nombre: así WinC se ha desarrollado apoyado en las MFC, en ActiveX y VBScripts, y en mucha menor medida, en OLE y COM. Ahora cualquier plan de evolución o migración debe partir de este hecho. Un escenario algo más mediado hubiera permitido ver el código c++ con un mayor grado de portabilidad. En fin, la encrucijada por .NET o no, es una propia de Microsoft, en un universo cada vez más abierto, y cuando el propio Visual Studio se ve obligado a contemplar extensiones para otros sistemas operativos. ¿Podría ser conveniente persistir en Visual Studio, y abordar a partir de allí la entrada a otros medios? en fin, la apertura de .NET se propone entrar en Linux y OS X . Apuesta dudosa...Pero esto requiere una nota aparte.
Mostrando las entradas con la etiqueta C#. Mostrar todas las entradas
Mostrando las entradas con la etiqueta C#. Mostrar todas las entradas
lunes, diciembre 08, 2014
sábado, mayo 31, 2014
Microsoft reenfocándose
Una noticia reciente poco comentada, pero quizá importante, ha sido la de abrir .NET y C# a proyectos open source, digamos, en mayor medida de lo hecho anteriormente. Recogido por Mary Jo Foley a comienzos de abril, pocos comentarios más se vieron en casi dos meses. Siguiendo a eWeek, Microsoft anunció en su conferencia Build 2014, sus planes en open source: la creación de una fundación (.NET Foundation), veinticuatro proyectos para iniciar actividades, y la conformación de una dirección integrada por funcionarios de Microsoft, de la subsidiaria Microsoft Open Technologies, y Miguel de Icaza. Entre los proyectos puestos en open source, está .NET Compiler Platform ("Roslyn"), y un par vinculados a Xamarin, la implementación de Miguel de Icaza de la plataforma de desarrollo.NET para dispositivos Android, iOS y GNU/Linux (el desarrollo completo en el comunicado de la fundación). En eWeek:
Microsoft formed the .NET Foundation to foster further innovation across the .NET ecosystem. The .NET Foundation will start with 24 .NET open-source projects under its stewardship, including the .NET Compiler Platform (previously known as "Roslyn") and the ASP.NET family of open-source projects, as well as the MimeKit and Mailkit libraries from Xamarin.Tanto de la lectura de los comunicados iniciales, como de los comentarios de Foley o Tim Anderson, se puede decir que lo más importante a la vista es la mayor colaboración con Xamarin e Icaza, y por lo tanto, un frente más en la apuesta por ganar un lugar en las tecnologías móviles. Tim Anderson pone especialmente el acento en este futuro móvil:
"We are going to be delivering a preview of the Roslyn compiler as a service," Somasegar said. "The most interesting thing that we're doing there is we are making both our C# compiler and our VB [Visual Basic] compiler open source. You want to be able to work with the community, you want to be able to take contributions back from the community, and you want to be able to work in the open. The other thing we are doing is adding support for .NET in Azure Mobile Services." -
The focus now though is on mobile, and interest in C# is stronger, mainly from Microsoft-platform developers reaching beyond Windows. There is also Unity, which uses C# as a scripting language for developing games for multiple platforms, including iOS, Android, Windows, Mac, Linux, Xbox, PS3 and Wii – PS4 is coming very soon.Una nueva acción en el sentido de adecuarse al rumbo actual y próximo del mercado tecnológico, como los movimientos de apertura de Office o los intentos de mejorar la posición de sus tabletas. ¿Con qué alcance? probablemente, destinado a ofrecer una alternativa al mercado propio en el ajeno de Android o iOS.
Microsoft has now consciously embraced multiple platforms, as evidenced by Office for iOS as well as the Xamarin collaboration. “We want C#developers to build great applications across different form factors and different device platforms,” said Jay Schmelzer Director of Program Management for Visual Studio.
You might observe that this position has been forced on the company by the rise of iOS and Android, a view which likely has some merit, but the impact it has on C# and .NET itself is still real.
¿Hasta qué punto este nuevo lanzamiento es open source? Si atendemos al inicio, en cuanto al carácter abierto de la fundación, su directiva es casi completamente Microsoft:
The new foundation will be initially staffed by Microsoft and third parties, including a representative from the Microsoft Open Technologies subsidiary and someone from the .NET organization, as well as Miguel de Icaza, CTO and co-founder of Xamarin, which is partnering with Microsoft on a related effort, Somasegar said.Mi primera impresión fue de sorpresa, ya en que demasiadas ocasiones las grandes empresas mandan a open source los productos que dejan de ser centrales en sus proyectos: una manera de reducir fondos a un producto que no está en sus planes, descargando en una comunidad el esfuerzo futuro de desarrollo. Sin embargo, en este caso, existe un deseo de mantener un control estricto sobre la conducción de la fundación, y existe un área de sumo interés futuro. En los artículos de Foley hay parecidas impresiones:
"There will be a board of directors," he said. "There are going to be a couple of people from Microsoft that are going to be on the board. There will be one person from MS Open Tech that's going to be on the board; there will be one person from the .NET team that will be on the board. We are also getting Miguel de Icaza to be on the board, so we'll have at least one third-party person on the board from Day 1. And we'll have a couple of third-party projects, including efforts from Xamarin and others. Our plan is, over time, to expand the board to include more people. There will be a board that will govern the .NET Foundation. Microsoft will initially have a strong presence, but it will not be exclusively Microsoft."
I have to admit that I wasn't sure if Microsoft's decision to open-source more of .Net would be met by cheers or jeers by those attending Build last week. I was curious if developers might see the move as an indicator that Microsoft no longer considered .Net valuable enough to keep in-house as part of its collection of crown jewels. Most of the devs with whom I spoke at the show seemed upbeat about the move, however.El tiempo, más rápidamente que lo que nos podríamos pensar, irá diciendo a dónde va esta iniciativa. La competencia actual no da lugar a muchas dudas.
Hejlsberg told attendees of a press panel during Build that Microsoft is not abandoning .Net.
"We are actively investing in .Net going forward," Hejlsberg said, in response to an audience question as to whether Microsoft was putting .Net on the back burner.
"It's not going away," Hejlsberg said. "We are all in on .Net."
sábado, abril 26, 2014
A propósito de una API de c++
Hace algunos días me pidieron que estudiara alguna manera de validar que una fotografía cumplía con ciertos requisitos de densidad y medida en pixeles: un requerimiento simple, que exige acceder a metadatos de la imagen. Desde el punto de vista de nuestros modelos de Plex, esto significa usar un API, ya que no existen dentro del conjunto de funciones propias del producto, ni tampoco en ninguno de sus patrones de tecnología, alguna función preelaborada que permita obtener esa información.
Un API es un trozo de código específico de una plataforma que funciona encapsulado: en su interior resuelve una necesidad específica, en este caso, tratar metadatos de una imagen, intercambiando información con el modelo a través de parámetros. Así, el modelo se mantiene a nivel abstracto, y se relaciona con código específico de plataforma a través de un marco de inicialización que resuelve la relación entre el nivel del modelo y el del código encapsulado. El marco de las APIs que Plex maneja es relativo a plataformas específicas: c++ para clientes Windows de código no administrado (en términos del marco .NET) u ODBC, un motor de VBscript incrustado para VBscript, c# para .NET, y java o RPG para las variantes respectivas. Ya hace tiempo existe en la comunidad de Plex el estilo de definir un API de tal forma que responda a múltiples plataformas, por medio de metaoperaciones, que permitan intercambiar los parámetros entre el modelo y el código encapsulado, que será uno distinto por variante, y se resolverá en tiempo de compìlación según metaoperaciones que interroguen al modelo acerca de qué lenguaje se ha configurado. De esta forma, un sólo objeto API permite representar en un modelo su solución para tantas variantes como sea necesario y posible.
¿Estas son las únicas variantes posibles? Aunque hasta donde conozco, nadie lo ha intentado, existe una posibilidad de "sobrecargar" Plex para agregar APIs de otra plataforma o lenguaje: Plex sigue el modelo .COM, y permite importar un componente, y utilizar sus métodos y variables públicas como parte del modelo. Es entonces posible añadir transformaciones que habiliten otra variante, al menos al nivel puntual de una API. Utilizando elementos similares por otra vía, Websydian primero, y Webclient después, permitieron agregar capas de arquitectura web completas a un modelo de Plex.
Pero ahora, volviendo al pedido de lectura de metadatos de imágenes...Primero, restringimos el alcance del API a una aplicada a un modelo WinC, es decir, uno de plataforma Windows de modelo Win32, al menos para su primera versión: el horizonte de aplicación abarca por lo menos los próximos tres años. No está claro si en el futuro la aplicación continuará sobre Windows o Java, y en el primer caso, si sobre Win32 o WinRT. Digamos de todas formas que WinRT todavía no está soportado sobre Plex, lo que estrechaba el marco de posibilidades. Ahora bien, ¿qué alternativas hay disponibles para trabajar con imagenes escritas en c++ o c? En una primera revisión, encontré varias alternativas; Adobe XMP Toolkit, ExifTool (en modo de línea de comandos), Exiv2, y especialmente el Windows Imaging Component, o el objeto PropertyItem (en System.Drawing.Imaging Namespace) , ambos de Microsoft. Con algo de entusiasmo, comencé pesando las posibilidades de estas dos alternativas de Microsoft. Trabajando con Visual Studio y sobre una plataforma Windows ¿qué alternativa más "natural" puede considerarse que la del propietario de la plataforma? Sin embargo, luego de revisar la documentación (algo escasa en general), encuentré su uso demasiado exigente para el caso que debíamos atender: En primer lugar, la clase PropertyItem parecía más simple y directa de usar (a pesar de que tampoco estamos hablando de pocas líneas de código), pero aparecieron un par de observaciones (1, 2) que es necesario tener en cuenta, sin hablar de las posibles dependencias de versión del framework .NET. En el caso de WIC, examinando la documentación claramente marchabamos a matar moscas a cañonazos. Tanto por la complejidad relativa al objetivo a resolver, como también por la ambigua situación de evolución y deriva de .NET, Win32 y WinRT,decidí volver a evaluar otras opciones de código abierto, y finalmente adopté Exiv2, pero aún de una manera más simple: no recurriendo a la librería c++, sino usando el comando de consola exiv2, que permite acceder a la mayoría de los estándares de metadata...sin necesidad de asegurarse de que estén instalados los codecs adecuados...
En fin, resuelta la estrategia, en un par de días cerramos el problema con un código simple, reducido, y fácilmente ampliable a la obtención de otros atributos. En una situación de transición de la plataforma de Windows como la actual, es preferible quedar libre de dependencias y compromisos, si es posible. En tanto, ActiveX, VBA, VB for Office, c++ y en alguna medida .NET y .COM, atraviesan la borrosa frontera entre Win32, WinRT y otras alternativas que puedan sumarse a "un solo Windows"...
Un API es un trozo de código específico de una plataforma que funciona encapsulado: en su interior resuelve una necesidad específica, en este caso, tratar metadatos de una imagen, intercambiando información con el modelo a través de parámetros. Así, el modelo se mantiene a nivel abstracto, y se relaciona con código específico de plataforma a través de un marco de inicialización que resuelve la relación entre el nivel del modelo y el del código encapsulado. El marco de las APIs que Plex maneja es relativo a plataformas específicas: c++ para clientes Windows de código no administrado (en términos del marco .NET) u ODBC, un motor de VBscript incrustado para VBscript, c# para .NET, y java o RPG para las variantes respectivas. Ya hace tiempo existe en la comunidad de Plex el estilo de definir un API de tal forma que responda a múltiples plataformas, por medio de metaoperaciones, que permitan intercambiar los parámetros entre el modelo y el código encapsulado, que será uno distinto por variante, y se resolverá en tiempo de compìlación según metaoperaciones que interroguen al modelo acerca de qué lenguaje se ha configurado. De esta forma, un sólo objeto API permite representar en un modelo su solución para tantas variantes como sea necesario y posible.
¿Estas son las únicas variantes posibles? Aunque hasta donde conozco, nadie lo ha intentado, existe una posibilidad de "sobrecargar" Plex para agregar APIs de otra plataforma o lenguaje: Plex sigue el modelo .COM, y permite importar un componente, y utilizar sus métodos y variables públicas como parte del modelo. Es entonces posible añadir transformaciones que habiliten otra variante, al menos al nivel puntual de una API. Utilizando elementos similares por otra vía, Websydian primero, y Webclient después, permitieron agregar capas de arquitectura web completas a un modelo de Plex.
Pero ahora, volviendo al pedido de lectura de metadatos de imágenes...Primero, restringimos el alcance del API a una aplicada a un modelo WinC, es decir, uno de plataforma Windows de modelo Win32, al menos para su primera versión: el horizonte de aplicación abarca por lo menos los próximos tres años. No está claro si en el futuro la aplicación continuará sobre Windows o Java, y en el primer caso, si sobre Win32 o WinRT. Digamos de todas formas que WinRT todavía no está soportado sobre Plex, lo que estrechaba el marco de posibilidades. Ahora bien, ¿qué alternativas hay disponibles para trabajar con imagenes escritas en c++ o c? En una primera revisión, encontré varias alternativas; Adobe XMP Toolkit, ExifTool (en modo de línea de comandos), Exiv2, y especialmente el Windows Imaging Component, o el objeto PropertyItem (en System.Drawing.Imaging Namespace) , ambos de Microsoft. Con algo de entusiasmo, comencé pesando las posibilidades de estas dos alternativas de Microsoft. Trabajando con Visual Studio y sobre una plataforma Windows ¿qué alternativa más "natural" puede considerarse que la del propietario de la plataforma? Sin embargo, luego de revisar la documentación (algo escasa en general), encuentré su uso demasiado exigente para el caso que debíamos atender: En primer lugar, la clase PropertyItem parecía más simple y directa de usar (a pesar de que tampoco estamos hablando de pocas líneas de código), pero aparecieron un par de observaciones (1, 2) que es necesario tener en cuenta, sin hablar de las posibles dependencias de versión del framework .NET. En el caso de WIC, examinando la documentación claramente marchabamos a matar moscas a cañonazos. Tanto por la complejidad relativa al objetivo a resolver, como también por la ambigua situación de evolución y deriva de .NET, Win32 y WinRT,decidí volver a evaluar otras opciones de código abierto, y finalmente adopté Exiv2, pero aún de una manera más simple: no recurriendo a la librería c++, sino usando el comando de consola exiv2, que permite acceder a la mayoría de los estándares de metadata...sin necesidad de asegurarse de que estén instalados los codecs adecuados...
En fin, resuelta la estrategia, en un par de días cerramos el problema con un código simple, reducido, y fácilmente ampliable a la obtención de otros atributos. En una situación de transición de la plataforma de Windows como la actual, es preferible quedar libre de dependencias y compromisos, si es posible. En tanto, ActiveX, VBA, VB for Office, c++ y en alguna medida .NET y .COM, atraviesan la borrosa frontera entre Win32, WinRT y otras alternativas que puedan sumarse a "un solo Windows"...
domingo, marzo 04, 2012
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:
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.
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.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)
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.
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.
domingo, abril 10, 2011
Lenguajes de programación y rankings
Reviendo dos rankings de lenguajes de programación: Tiobe y The Transparent Language Popularity Index, éste último, en Source Forge (apuntado por Jean Bezivin). Coincidencias básicas entre ambos para los primeros puestos: con leves diferencias, Java, C, C++, PHP, C#. En ambos rankings, no se habla de número de aplicaciones, líneas de código, ponderación de la importancia de las aplicaciones involucradas. Fundamentalemnte, lo que establece su importancia es la popularidad del lenguaje. La fórmula de Tiobe lo explica:
En el último tiempo, suele hablarse de Java como un lenguaje "corporativo", igualándolo a "legacy". Su continuidad en la primera línea en todo caso muestra que su interés no se ha amortiguado.
The ratings are calculated by counting hits of the most popular search engines. The search query that is used is¿Son importantes estos índices? La popularidad implica que han ocupado la atención pública, que fue analizado para su adopción, que distintas comunidades recurrieron a consultas para resolver problemas o educarse, en fin, que estuvieron en el foco de la atención de la comunidad de la industria. Pero no habla en todo caso de los consolidados, aquellos que se usan sin ruido, y que pueden ser usados también en abundancia, como sin duda sucede con COBOL, RPG y otros.
+"This search query is executed for the top 6 websites of Alexa that meet the following conditions:programming"
Based on these criteria currently Google (32%), YouTube (10%), Yahoo! (3%), Bing (3%), Wikipedia (16%), Blogger (32%) and Baidu (3%) are used as search engines. The number of hits determine the ratings of a language. The counted hits are normalized for each search engine for the first 50 languages. In other words, the first 50 languages together have a score of 100%. Let's define "hits50(SE)" as the sum of the number of hits for the first 50 languages for search engine SE and "hits(PL,SE)" as the number of hits for programming language PL for search engine SE. Possible false positives for a query are already filtered out in the definition of "hits(PL,SE)". This is done by using a manually determined confidence factor per query. A query such as "Basic programming" also returns pages that contain "Improve your basic programming skills in Java". The first 100 pages per search engine are checked for possible false positives and this is used to define the confidence factor. If this factor is 90%, then only 90% of the hits are used for "hits(PL,SE)". An overview of the confidence factor can be found in the groupings table below.
- The entry page of the site contains a search facility
- The result of querying the site contains an indication of the number of page hits
The ratings are calculated with the following formula:
((hits(PL,SE1)/hits50(SE1) + ... + hits(PL,SEn)/hits50(SEn))/nwhere n is the number of search engines used.
En el último tiempo, suele hablarse de Java como un lenguaje "corporativo", igualándolo a "legacy". Su continuidad en la primera línea en todo caso muestra que su interés no se ha amortiguado.
domingo, marzo 01, 2009
Lenguajes de computador: Preferencias en la lectura
El 25 de febrero, Mike Hendrickson analiza en O´Reilly las cifras de la editorial acerca de la venta de materiales dedicados a lenguajes de computación. ¿Cuánto tienen que ver estos números con su uso real? En cierto modo marcan tendencias, pero sólo si se lo observa en un período mediano de plazo, para diferenciar tendencias duraderas respecto de las "olas". Un caso claro es el del COBOL, con menos de mil libros vendidos. ¿Podríamos concluír que su uso es menor que el de c#, java o c++, con cifras variando entre los 170.000 y 270.000 libros?. En realidad, se trata del interés prestado a uno y otro. Lo que les interesa a quienes agregan conocimiento e investigan. Pero el uso real es una combinación de pragmatismo, conservadorismo e innovación, y la persistencia del COBOL da fuerza a los dos primeros elementos.
Suscribirse a:
Entradas (Atom)