Desde que Steve Ballmer anunció que Microsoft se lo jugaba todo a la carta de la computación en forma de 'nubes' (si, todos odiamos el término, pero no merece la pena rebelarse) no se han oido muchas cosas sobre el tema. Sin embargo, en el breve espacio de dos días se han producido dos noticias muy reveladoras.
En una de ellas, Microsoft acaba de convencer al Estado de Minnesota para que migre a 30.000 de sus usuarios a Azure. Que yo sepa, este es uno de los primeros grandes casos de migración masiva a una nube, y tal vez advertencia de lo que se viene encima a los sysadmins en los años venideros. Las compañías o instituciones que adopten este modelo no quieren tener un departamento de IT, del mismo modo que no quieren tener un taller de reparación de coches propio. Prefieren "subcontratar" todo lo que puedan a la nube, hacer que los clientes se autentifiquen y comuniquen con una instancia Azure ubicada en servidores de Microsoft en lugar de hacerlo en un servidor local. Como plantilla de IT se mantiene a los programadores que desarrollen aplicaciones para la nube (o se subcontrata a una consultora), y poco más. Las empresas se ahorran complejidad y parece ser que también dinero.
Pero no nos vayamos por las nubes (¿Lo han pillado? Ja. Ja.): Cuando hablamos de movimientos de IT en instituciones, es inevitable hablar de lobbing. ¿Cuánto dinero se ha gastado Microsoft en intentar convencer a Minessota? ¿Qué generosas ofertas les ha hecho, con cargo a las deudas de Microsoft, solo por conseguir un cliente que puede funcionar como marketing -"miren lo que hicieron en Minessota"- para abrirle la puerta de muchos otros? Que conste que no pretendo acusar a nadie de malas prácticas, esto es algo normal en cualquier negocio. Pero solo el tiempo nos aclarará lo verdaderamente efectivo, sencillo y costoso que puede llegar a ser la idea esta de deslocalizar departamentos de IT a un cluster.
Por otro lado, Microsoft ha anunciado que Live Spaces, su plataforma de blogs, pasa a mejor vida, y se pasa a Wordpress. Lo cual es completamente alucinante. A ver, Microsoft tuvo un déficit de 696$ millones en su división online en el último trimestre, eso son 6$ millones perdidos al día (gastar, gastan aun más). ¿Y no son capaces de desarrollar una plataforma de blogs decente? Dicen que van a "apostar todo en la nube", que quieren convertirse en los reyes de internet. ¿Merece dominar Internet una empresa que tiene que "deslocalizar" algo tan esencial como los blogs? ¿Con qué argumentos va a vender la moto de Windows+IIS+ASP.Net+SQL Server una compañía que tiene que deslocalizar su plataforma de blogging a otra basada en LAMP? Si Azure es tan potente...¿por qué no reconvertir Live Spaces, Hotmail, y los demás servicios gratuitos de Live para funcionar en una especie de instancia gratuita Azure independiente para cada usuario?
Resumiéndolo en una pregunta: ¿Puede fiarse Minessota de mover toda su
infraestructura a Azure, cuando el propio creador de Azure no es capaz
de desarrollar una plataforma de blogs exitosa sobre su propio invento?
30 de septiembre de 2010
26 de septiembre de 2010
Oracle y el trono perdido de Java ME
The Register tiene este domingo un interesante artículo (consecuencia de este otro) sobre los planes de Oracle para la versión de Java para móviles, Java ME. Junto al ataque legal por patentes de Java a Google, parece obvio que Oracle pretende sustituir a Android como plataforma Java para móviles, y ya de paso adelantar a todas las demás. Desde luego, al señor Ellison no se le puede acusar de no tener más moral que el Alcoyano.
Si mi memoria no me falla, en todos los artículos que he leido en todos estos años desde que el iPhone inauguró la "tactilitis", no he leido a nadie mencionar a Java ME como plataforma de desarrollo con futuro. A día de hoy el éxito de una plataforma para teléfonos móviles se cuenta por el número de aplicaciones disponibles en su tienda de aplicaciones, y los números son estos: 250.000 para iPhone, 120.000 para Android, 7.422 para Blackberry, 6.118 para Nokia, 4.475 para Palm y 1.200 para Microsoft. Sun anunció con mucha grandilocuencia la que iba a ser la tienda de aplicaciones más grande del mundo, para aplicaciones Java de todo tipo, multiplataforma y todo eso, pero a día de hoy aun está en beta, y de una versión específica o una adaptación para Java ME no se sabe nada.
Resulta sorprendente que Oracle tenga fe en Java ME. Para empezar, porque a día de hoy se ha convertido en sinónimo de "obsoleto". La propia noticia detalla las mejoras que Oracle planea (es decir, planea añadir en el futuro, aun no están disponibles): aceleración gráfica para crear interfaces fluidas. Guste o no, el iPhone es quien ha sentado las bases de lo que se considera "requisitos mínimos" en un teléfono móvil, y la aceleración gráfica que hace más intuitiva las necesarias transiciones de las interfaces táctiles está entre esos requisitos. Para hacerse una idea, vean esta captura del toolkit con el que andaban coqueteando, inspirado en Swing. Ahora pasan de eso y parece ser que quieren usar JavaFx, imitando a Microsoft con Silverlight en el Windows Phone 7. Solo que Oracle está aun más retrasado que ellos.
Pero hay otro problema con Java ME, que es la fragmentación. A Sun siempre le gustó llenarse la boca con palabras bonitas sobre la multiplataforma de Java, hablar sobre el "ejecutar en cualquier sitio", pero la realidad es distinta. Java ME como plataforma estaba muy fragmentada, no tanto por la plataforma en si, sino por las diferentes configuraciones de hardware existentes y la manera en la que los fabricantes lo integraban en sus teléfonos. En realidad, este es el mismo riesgo que Android sufre -en realidad ya está sufriendo-, que una aplicación funcione o deje de funcionar dependiendo del modelo de teléfono.
Uno no puede evitar pensar que Oracle lo hubiera tenido más fácil intentando adoptar la plataforma Android como sustituto de ME, en vez de intentar -inútilmente- de cargársela y sustituirla, que es algo que difícilmente va a lograr. Especialmente teniendo en cuenta que a Oracle le falta algo crítico: un sistema operativo para móviles. Pero oiga, si Ellison cree que Html5 es una chapuza y que JavaFx es la mejor manera de programar páginas web y que no hay nada más que discutir [1], ¿por qué no iba a creer que Java ME puede eclipsar al resto de plataformas de desarrollo para teléfonos móviles? Quizás Apple acabe rindiéndose a sus pies y pidiéndoles que les ayuden a incluir Java ME en el iPhone.
[1]: A pesar de que Ellison piensa eso, la realidad es que en JavaFx 2.0 han cambiado completamente su punto de vista. Han añadido un motor de aceleración gráfica que, aparte de renderizar en DirectX o OpenGL, también será capaz de hacerlo en Html5. Si, como suena: escribir aplicaciones que se visualizen en Html5 pero escritas inicialmente en JavaFx, supongo que al estilo del Google Web Toolkit.
Si mi memoria no me falla, en todos los artículos que he leido en todos estos años desde que el iPhone inauguró la "tactilitis", no he leido a nadie mencionar a Java ME como plataforma de desarrollo con futuro. A día de hoy el éxito de una plataforma para teléfonos móviles se cuenta por el número de aplicaciones disponibles en su tienda de aplicaciones, y los números son estos: 250.000 para iPhone, 120.000 para Android, 7.422 para Blackberry, 6.118 para Nokia, 4.475 para Palm y 1.200 para Microsoft. Sun anunció con mucha grandilocuencia la que iba a ser la tienda de aplicaciones más grande del mundo, para aplicaciones Java de todo tipo, multiplataforma y todo eso, pero a día de hoy aun está en beta, y de una versión específica o una adaptación para Java ME no se sabe nada.
Resulta sorprendente que Oracle tenga fe en Java ME. Para empezar, porque a día de hoy se ha convertido en sinónimo de "obsoleto". La propia noticia detalla las mejoras que Oracle planea (es decir, planea añadir en el futuro, aun no están disponibles): aceleración gráfica para crear interfaces fluidas. Guste o no, el iPhone es quien ha sentado las bases de lo que se considera "requisitos mínimos" en un teléfono móvil, y la aceleración gráfica que hace más intuitiva las necesarias transiciones de las interfaces táctiles está entre esos requisitos. Para hacerse una idea, vean esta captura del toolkit con el que andaban coqueteando, inspirado en Swing. Ahora pasan de eso y parece ser que quieren usar JavaFx, imitando a Microsoft con Silverlight en el Windows Phone 7. Solo que Oracle está aun más retrasado que ellos.
Pero hay otro problema con Java ME, que es la fragmentación. A Sun siempre le gustó llenarse la boca con palabras bonitas sobre la multiplataforma de Java, hablar sobre el "ejecutar en cualquier sitio", pero la realidad es distinta. Java ME como plataforma estaba muy fragmentada, no tanto por la plataforma en si, sino por las diferentes configuraciones de hardware existentes y la manera en la que los fabricantes lo integraban en sus teléfonos. En realidad, este es el mismo riesgo que Android sufre -en realidad ya está sufriendo-, que una aplicación funcione o deje de funcionar dependiendo del modelo de teléfono.
Uno no puede evitar pensar que Oracle lo hubiera tenido más fácil intentando adoptar la plataforma Android como sustituto de ME, en vez de intentar -inútilmente- de cargársela y sustituirla, que es algo que difícilmente va a lograr. Especialmente teniendo en cuenta que a Oracle le falta algo crítico: un sistema operativo para móviles. Pero oiga, si Ellison cree que Html5 es una chapuza y que JavaFx es la mejor manera de programar páginas web y que no hay nada más que discutir [1], ¿por qué no iba a creer que Java ME puede eclipsar al resto de plataformas de desarrollo para teléfonos móviles? Quizás Apple acabe rindiéndose a sus pies y pidiéndoles que les ayuden a incluir Java ME en el iPhone.
[1]: A pesar de que Ellison piensa eso, la realidad es que en JavaFx 2.0 han cambiado completamente su punto de vista. Han añadido un motor de aceleración gráfica que, aparte de renderizar en DirectX o OpenGL, también será capaz de hacerlo en Html5. Si, como suena: escribir aplicaciones que se visualizen en Html5 pero escritas inicialmente en JavaFx, supongo que al estilo del Google Web Toolkit.
20 de septiembre de 2010
Microoptimización
En la próxima versión de Linux hay una microoptimización de código que me ha parecido interesante. El problema se origina en dos funciones con switch()s que contienen una cantidad considerable de cases, los cuales a su vez contiene varios ORs en cada uno: "case BPF_ALU|BPF_ADD|BPF_X".
Dado un switch(variable) con un montón de cases, el compilador normalmente no lo traduce a ensamblador tal y como los concibe el programador, es decir, como una secuencia de condiciones "si variable=A saltar a dirección x, si variable=B saltar a dirección y", sino como una especie de salto: "saltar a dirección x+variable". Sin embargo, parece ser que todos esos ORs de las funciones citadas impiden al compilador hacer su optimización (es más, según he leido en la wikipedia, parece ser que la misma secuencia de números que puede contener la variable puede afectar a la optimización).
Con lo cual esas funciones son ensambladas como una lista gigantesca de condiciones de 567 bytes de longitud. Sin embargo, eliminando los ORs se consigue que gcc optimize correctamente el código y todo sea como debiera de ser. Nótese que poner por separado todos esos ORs supone tener que crear un case adicional para cada uno, es decir, aumentar el número de líneas de código, pero contando la optimización lograda sigue siendo una mejora.
Estas cosas naturalmente no merece la pena ni mirarlas por regla general, pero si se trata de una parte del código cuyo rendimiento es crítico, como parece ser el caso, pues quizás si. El otro día recuerdo haber leído un artículo (lamento no poder recuperar el enlace) de un experto en análisis que afirmaba que la parte del código más importante para el rendimiento de un programa solía ser el 1% de todo el código, y que normalmente los programadores no suelen analizarlo, a pesar de que se pueden lograr mejoras notables con pequeñas optimizaciones. No es mala advertencia, desde luego.
Y si han llegado hasta aquí tal vez les interese saber que ya se pueden ver las primeras capturas de cómo se está portando QT (también se está portando GTK, tengo entendido) para funcionar de manera nativa en Wayland, que es un servidor gráfico alternativo a X.org basado en las últimas tecnologías gráficas de Linux.
Dado un switch(variable) con un montón de cases, el compilador normalmente no lo traduce a ensamblador tal y como los concibe el programador, es decir, como una secuencia de condiciones "si variable=A saltar a dirección x, si variable=B saltar a dirección y", sino como una especie de salto: "saltar a dirección x+variable". Sin embargo, parece ser que todos esos ORs de las funciones citadas impiden al compilador hacer su optimización (es más, según he leido en la wikipedia, parece ser que la misma secuencia de números que puede contener la variable puede afectar a la optimización).
Con lo cual esas funciones son ensambladas como una lista gigantesca de condiciones de 567 bytes de longitud. Sin embargo, eliminando los ORs se consigue que gcc optimize correctamente el código y todo sea como debiera de ser. Nótese que poner por separado todos esos ORs supone tener que crear un case adicional para cada uno, es decir, aumentar el número de líneas de código, pero contando la optimización lograda sigue siendo una mejora.
Estas cosas naturalmente no merece la pena ni mirarlas por regla general, pero si se trata de una parte del código cuyo rendimiento es crítico, como parece ser el caso, pues quizás si. El otro día recuerdo haber leído un artículo (lamento no poder recuperar el enlace) de un experto en análisis que afirmaba que la parte del código más importante para el rendimiento de un programa solía ser el 1% de todo el código, y que normalmente los programadores no suelen analizarlo, a pesar de que se pueden lograr mejoras notables con pequeñas optimizaciones. No es mala advertencia, desde luego.
Y si han llegado hasta aquí tal vez les interese saber que ya se pueden ver las primeras capturas de cómo se está portando QT (también se está portando GTK, tengo entendido) para funcionar de manera nativa en Wayland, que es un servidor gráfico alternativo a X.org basado en las últimas tecnologías gráficas de Linux.
Suscribirse a:
Entradas (Atom)