Geek & Roll

Estaba esperando a que se calmaran los ánimos con aquello de la demanda de Oracle a Google con respecto a su uso de Java, para poder empezar a leer opiniones informadas sobre el tema y no el típico argumento de “Maldito Oracle, con ellos todo es sobre el dinero” o de “Pero Dalvik no es Java, estúpido Oracle” o de “Google tan buenos ayudando a Java a ser más popular y Oracle que los demanda, los odio”.

Pero ese tiempo aún no llega. El post más informado sobre el tema lo leí en el blog de Osvaldo Pinali, donde argumenta que Java es igual que Dalvik, es decir la máquina virtual (VM) que Google implementó para su sistema Android es, en esencia, lo mismo que Java. Tan es así que puede existir una herramienta relativamente sencilla que convierta las clases compiladas por Java del formato binario .class propio de Java al .dex propio de Dalvik. A nivel de código fuente es exactamente lo mismo con sus java.lang y toda la cosa. Convertir código compilado de Java a cualquier otra cosa es algo muy complejo, pregúntenselo a IKVM que ha tratado por años de convertir Java a .NET y le sigue costando bastante trabajo.

El punto es que la demanda tiene más trasfondo. Claro que tiene que ver con sacarle el mayor dinero posible a Google, pero también tiene que ver con el hecho de que Google en vez de pagarle a Sun por usar la Java VM, prefirió irse por el lado de implementar la propia y sacarle la vuelta al licenciamiento. Por supuesto que ya que iban a implementar una VM nueva, pues había que mejorar la existente y quien mejor que Google que tiene los recursos económicos y el conocimiento técnico.

Google no quiso pagar como lo hacen otros, RIM (los de la BlackBerry) por dar un ejemplo. Ahora Oracle quien se encuentra en una posición económica mucho mejor que la extinta SUN decide ir tras ellos, idea supuestamente producto del entonces CEO de SUN Jonathan Schwartz y que le plantó a Larry Ellison. Si Google hubiera decidido pagar a SUN por el uso de su tecnología, quien sabe, a lo mejor SUN todavía existiría (pero quien sabe, porque tenían una habilidad como pocos para no capitalizar).

Volviendo al tema de Dalvik (Android) y Java, ellos dos son uno mismo. Yo si pienso que Google con Android y GWT, ha ayudado a que más personas programen en Java haciéndolo aún más popular. Se agradece, pero eso no lo exenta de una demanda al tratar de sacarle la vuelta a las patentes de Oracle (por más ridículas que sean las patentes de software) ni convierte a Google en “el bueno”. Google sabía perfectamente lo que estaba haciendo y deliberadamente hizo a su VM compatible con Java, sus librerías y herramientas disponibles. Microsoft se encontraba en la misma situación al crear .NET, pero decidió tomar el camino más largo.

Así que quien es el malo, ¿Oracle, Google, ambos o ninguno?

Desde que Google mostró al mundo su port de Quake 2 a JavaScript usando GWT, no me podía sacar una pregunta de la cabeza: ¿Cómo hacen para cargar los recursos (como por ejemplo los modelos de los jugadores, o los niveles) desde el servidor al cliente, para su uso por el motor del juego en JavaScrip? ¿Es posible obtener archivos binarios del servidor, guardarlos en el sistema de archivos local, y ejecutarlos finalmente por una aplicación en JavaScript? La respuesta obviamente era sí, pero no sabía cómo.

Pero una consulta al código fuente del proyecto quake2-gwt aclaró las dudas. El secreto es sobreescribir un tipo MIME, lo que le permite al objeto XMLHttpRequest recibir respuestas binarias en vez de texto, para lo cual es más comúnmente utilizado.

function load_binary_resource(url) {
  var req = new XMLHttpRequest();
  req.open('GET', url, false);
  //XHR binary charset opt by Marcus Granado 2006 [http://mgran.blogspot.com]
  req.overrideMimeType('text/plain; charset=x-user-defined');
  req.send(null);
  if (req.status != 200) return '';
  return req.responseText;
}

En GWT necesitamos hacer uso de una funcion JavaScript nativa (JSNI) para lograr lo mismo:

private native void overrideMimeType(XMLHttpRequest req, String mimeType) /*-{
    req.overrideMimeType(mimeType);
}-*/;

Y finalmente crear un objeto XMLHttpRequest, hacer la petición y procesar los datos binarios en el cliente:

XMLHttpRequest req = XMLHttpRequest.create();
overrideMimeType(req, "text/plain; charset=x-user-defined");

req.setOnReadyStateChange(new ReadyStateChangeHandler(){
    //procesar la respuesta binaria
});

req.open("GET", "archivo.binario");
req.send();

Para convertir la respuesta en un InputStream, en este caso utilizando GWT y clases de emulación io y nio que tomé prestadas del proyecto quake2-gwt:

response = xhr.getResponseText();
byte[] responseBytes = new byte[sbb.stringToByteBuffer(response).remaining()];
InputStream inputStream = new ByteArrayInputStream(responseBytes);

En este punto pueden usar el InputStream como lo harían en un programa Java tradicional, por ejemplo si cargaron los bytes de una imagen, pueden aplicarle filtros a-la-photoshop, en tiempo real, en el cliente, sin necesidad de procesamiento en el servidor mas allá de descargar la imagen.

Los fanboys de Apple (mactards como les llama el Sr. Boynacoras) son una raza extraña. Cuando las macs eran PPC, los procesadores x86 eran lentos y para naquitos, después las macs se pasaron a intel y ahora son la 8va maravilla. Cuando las macs se vendían poco es porque eran para la élite, y ahora que cualquier hijo de vecino tiene una mac, iPhone, iPod o iPad se enorgullecen del éxito en ventas.

Y ahora que se venden más androids que iPhones… ¡¡¡lloren niños lloren!!!

1. Excusa mactard #1: Esa comparación no vale porque solo hay un iPhone y hay muchos dispositivos android. Eso no tiene nada que ver, el artículo específicamente habla sobre mayor venta de smartphones android contra smartphones iPhone. El hecho de que existan varios modelos distintos de smartphones que pueden ejecutar android no tiene nada que ver. Una comparación injusta sería comparar la venta de cualquier dispositivo que corre android vs solamente el iPhone, pero no es el caso. Además, en el pasado se han comparado las ventas de iPhone vs dispositivos BlackBerry y ahí nadie se quejó de la existencia de muchos modelos de BlackBerry.
2. Excusa mactard #2: Es que el iPhone no se vende porque se están esperando al modelo nuevo. La realidad es que, en android, salen modelos nuevos más seguido y esa misma razón ha sido señalada como una debilidad en la comunidad android. ¿Ahora resulta que es una debilidad en el mundo iPhone también?
3. Excusa mactard #3: Pero el iPhone es más bonito. Hmmm… si.

El hecho es que, en este momento se están vendiendo más smartphones androids que iPhones, y eso es muy bueno para el consumidor. Eso fomenta la competencia y el avance de esas dos plataformas, además de sus competidores como BlackBerry e inclusive WebOS que se rumora verá la luz controlando una tablet.

El tema caliente de la semana es Google Buzz. Para muchos un quierosertwitter, para otros Twitter como debió ser desde el inicio. ¿Pero que opinan los Geek&Rollers del tema? Veamos:

Axel

No lo he checado porque me enmulé porque no hay en google apps for your domain, pero lo checo y te envío la opinión.

Rafyta

O sea que como no pego el wave a ver si con esta onda se arma?

Boynas

Cuantas veces hemos discutido en twitter y hemos sentido que es molesto para los que siguen nuestro timeline (respeto a los demas en contra de la funcionalidad).
La integracion a otros servicios tanto de fotografias, videos y contenido en general, se me hace menos forzada que la de twitter. Tiene mas features nativos.

Lo mas importante es que es mainstream. No necesito enseñar a un amigo a usarlo, es simple y amigable. A mi me interesa seguir a todo mundo no solo a geeks o a media freaks pesudo-periodistas, que son los que se meten a twitter. Esa es la unica razon por la que tengo FB!
Creo que Buzz es como twitter made right, tiene las threaded comments de FB sin las molestas apps; Sin embargo es ordenado no necesitas brincar de timeline en timeline para seguir una conversacion en la que comento una persona que no conoces.

Buzz esta tapando ese gap. Es lo que debio haber hecho twitter con su red de usuarios hace mucho tiempo.. Es perfectamente un twitter killer. (no mames, hasta rima)

César

Tiene más sentido que Twitter, para mi. Gmail siempre esta abierto en mi navegador. Ahora nomas falta que todos dejen de usar Hotmail y se pasen a Gmail, cosa que no se por qué no ha sucedido todavía. Ah, y que le arreglen eso de que se autorefresca el sitio pero te sigue marcando items no leídos. Y una opción para que cuando leo algo en Buzz, no me aparezca como no leído en la bandeja de entrada de Gmail.

Lo mejor de todo es que, en mi opinión, los clientes exclusivos van a perder relevancia, haciendo mucho más relevantes cosas como lo que está haciendo Ubuntu con su Me Menu y Gwibber. Si todo sale bien, vamos a estar un paso adelante. Eso si, su uso desde el Web siempre va a ser una mejor experiencia, como Google nos tiene acostumbrados.

¿De acuerdo? ¿Desacuerdo? Usen la caja de comentarios. Nos vemos en Buzz.

La buena: ya hay push para GMail en el iPhone.
La mala: sólo una cuenta por iPhone y sólo te avisa cuando la pantalla está encendida, o estás conectado a la corriente.
Querido Google: Gracias

O cómo años de cochinada te aplican la ley de Herodes: o te chingas, o te jodes.

El día de hoy se publicó la versión 8 del navegador más utilizado en el mundo: Internet Explorer. Más utilizado no necesariamente significa mejor, aunque en este caso definitivamente es una versión superior a su antecesor en muchos aspectos. IE8 es más seguro, más rápido y más respetuoso de los estándares; y tiene que serlo, años de negligencia y una creciente inconformidad con la oferta de Microsoft provocaron que Firefox se convirtiera en una seria amenaza y navegadores alternativos se colocaran en el ojo del público en general (Opera, Safari), además de Chrome, el nuevo navegador de Google, todo un trendsetter. En Ars Technica hacen una excelente reseña de las nuevas características de IE8.

Pero años y años de ignorar estándares, o inventarse los propios, puso a los ingenieros de Microsoft en una terrible disyuntiva: o arreglamos nuestro cochinero y en el proceso nos cargamos a todos los desarrolladores Web que pasaron incontables horas depurando para IE, o seguimos manteniendo el cochinero y de alguna manera tratamos de que no suceda más. Eligieron lo segundo (para sorpresa de nadie, creo yo, si la historia de compatibilidad de Windows ha servido de algo).

La mecánica que siguieron es la siguiente (muy simplificada): hacemos a IE8 lo más apegado a estándares que se pueda (muy bueno), y proporcionamos a los usuarios la posibilidad de renderear el sitio en modo compatibilidad por si rompemos algo (so so). Pero rápidamente se dieron cuenta que pedirle a los usuarios presionar un botón para que un sitio se vea bien, siendo que con la versión anterior no tenían problema, y especialmente tomando en cuenta que fueron ellos mismos (Microsoft) los que provocaron que esos sitios estuvieran llenos de parches, hacks y workarounds para funcionar bien con IE, no era suficiente.

En respuesta a esto, y para tratar de aliviar la situación, proporcionaron un mecanismo para indicarle al navegador cómo renderear el sitio sin necesidad de presionar botón alguno. Completamente transparente para el usuario. La solución es enviar un encabezado HTTP especial en la respuesta, de esta manera el navegador sabe que hacer.

Ahora, la solución puede parecer relativamente fácil, pero el trabajo lo llevan los desarrolladores Web. En primera, son ellos los que año tras año, y versión tras versión han tenido que sacarle la vuelta a los modos irrespetuosos de IE. Ahora IE viene y te dice “Ok, ahora sí funciono como se supone, pero tienes que hacerme este último favorsito…”. Y la ironía no sería tan graciosamente torcida de no ser que IE deja por fuera la etiqueta canvas, al mismo tiempo que discontinúa VML y le da un certero golpe a muchos sitios y librerías que implementan cosas como esquinas redondeadas con VML cuando el usuario usa IE (y canvas o SVG cuando no).

En lo personal el problema me pegó al probar averalcine.com en IE8. Lightbox no funciona, tan solo en modo de compatibilidad. Y ni modo, a mandar un encabezado HTTP que no tendría porque.

Aunque Gmail, y en general las aplicaciones web de Google, están muy al pendiente del conetnido -y contexto- de tus mensajes y contenidos, no hay tencología que te impida mandar mensajes si estás en estado mmm… etílico… dudoso. Bueno, no había nada parecido hasta hace 12 días (6 de Octubre 2008) cuando Jon Perlow escribió Mail Goggles, un filtro que te pide resolver problemas de aritmética que un niño de primaria podría resolver mucho más rápidamente que tú.

El punto es que estés MUY seguro de lo que quieres mandar, y que tu pequeña mentecita esté en un estado los suficientemente funcional como para hacer sumas y restas sencillas. El filtro se activa a altas horas de la noche en fines de semana, o sea cuando andas de farra con tus amigotes. Una vez activado puedes añadir el quiebre de semana de los miércoles y bloquear los correos incoherentes que sueles mandar a tu ex o amigos del trabajo.

Prepárate y obten ese trabajo en Google que tanto has deseado:

Eso (escabullirte entre las preguntas del entrevistador) es lo que pasa casi siempre cuando obtienes una oferta de una compañía de tecnología. Tan solo lograste escabullirte. Gracias a la naturaleza fallida del proceso de entrevistas, es muy probable que alguien en la ronda de entrevistas no se impresione contigo, aún si eres Alan Turing. Especialmente si eres Alan Turing, de hecho, ya que significa que obviamente no sabes C++.

(Leído aquí)

En OSNews publicaron un artículo exclusivo sobre Chrome y las “verdaderas” razones por las que Google decidió lanzar su propio navegador. Es una lectura interesante. Traduzco del artículo:

Esa plataforma [HTML + Javascript] simplemente no fue hecha para hacerlo [aplicaciones Web] y está claro que no durará mucho. Y no, Google no podrá compilar Javascript a código nativo y hacerlo rapidísimo aún cuando ellos digan que si. Hay razones técnicas para eso y la única manera de hacerlo es cambiarse a un ambiente de tiempo de ejecución, justo como lo hace Flash, Silverlight y Java (y es no es nativo ya que ejecutan máquinas virtuales)

También:

Ellos [Google] probablemente aprendieron la lección mientras que observaban a Steve Jobs batallar por 8 años con su muñeca OS X y aún así depender del iPod para que le salvara el trasero. 8 años y aún tiene el ¿que? ¿2% del mercado?

El artículo completo en OSNews.

Se viene Google Chrome, el por años rumorado browser de Google. Habrá que esperar, pero las repercusiones de esto serán, creo yo, grandes.

Primero, habrá que ver que tanto se mueve el tapete de Mozilla Firefox. La mayoría de los usuarios de este último somos una bola de geeks, y algo que distingue a gran parte de este grupo es la afición casi desmedida por Google. ¿Qué podrá más, el poder y la capacidad de personalización de firefox o la seducción de la Angelina Jolie de las empresas de software? Seguramente Chrome vendrá cargado de facilidades para utilizar las aplicaciones web de Google, y eso es un golpe duro, muy duro para Mozilla.

Mis primeras impresiones (hasta ahora sólo con screenshots) no son muy emocionantes. La UI extra-simple de las aplicaciones web de Google parece —como era de esperarse— haberse pasado a este soft de escritorio, lo que es buenísimo, pero otras decisiones como el subir a las pestañas en la jerarquía de manera que cada una tiene su barra de direcciones es algo que sinceramente me incomoda. Claro, bajo esta lógica funcionan todos los navegadores con pestañas —la barra de dirección cambia cuando cambias de pestaña—, pero no sé si el hacerlo obvio visualmente sea una buena decisión.

Habrá que ver. Al momento en que leas esto probablemente tu lector de feeds esté plagado de reseñas de Chrome. Ojalá sean buenas, y sobre todo ojalá logremos mantener la objetividad.