No todo es JavaScript…

Microsoft lleva diciendo bastante tiempo que mejorar el rendimiento del navegador no se limita a conseguir mejores resultados en la suite de tests SunSpider (ayuda que IE8 sea el navegador más lento del mercado a la hora de ejecutar JavaScript, aunque todo parece indicar que, finalmente (cuando salga, que no va a ser ni mañana ni pasado), IE9 va a estar en números al menos comparables a los del resto del mundo). Pero parece que ahora desde Apple también van a tener que hacer proselitismo con el asunto, puesto que a alguien se le ha ocurrido ejecutar el test con Safari para iPhone y iPad y los resultados han sido bastante pobres, algo especialmente preocupante si tenemos en cuenta que Safari es Webkit, precisamente la gente que realizó el ‘benchmark’. Estoy convencido, además, que si se hace la prueba con un Nexus One el resultado tampoco va a ser muy allá (no me costaría nada creer que fuese aún peor)…

La cosa me provoca un par de reflexiones, así a bote pronto…

  • Por un lado, que me gustaría oír a alguien que no fuese Microsoft decir abiertamente que se van a dedicar a mejorar otras categorías de rendimiento más allá del JavaScript (¿para cuándo una suite de tests que compare cuánto tardan los diferentes navegadores en aplicar selectores de CSS3, por ejemplo?).
  • Por otro lado, se vendría a confirmar que portar Flash a los procesadores actualmente disponibles para dispositivos móviles es una tarea harto complicada, por no decir imposible a día de hoy, lo que explicaría la eternidad que estamos tardando en ver dispositivos de esa clase que ejecuten Flash.
Reblog this post [with Zemanta]

JavaScript is as evil

Los nuevos estándares abiertos creados en la era móvil, como HTML5, ganarán en los dispositivos móviles (y también en los PCs). quizá Adobe debería centrarse más en crear grandes herramientas HTML5 para el futuro, y menos en criticar a Apple por dejar el pasado atrás.

Sabias palabras de Steve Jobs. Permítanme jugarme un euro a que, además, son proféticas: en Flash CS5 ya hay una rudimentaria (o no tanto) exportación a Canvas. Muy estúpidos tendrían que ser en Adobe para que CS6 (o como se llame) no exporte básicamente todo lo que sea capaz de producir Flash a HTML5, Canvas y JavaScript1. Y entonces descubriremos que el «sabio» uso de las etiquetas <audio> y <video> es capaz de producir las mismas aberraciones a que ha dado lugar el mal uso de Flash a lo largo de los diez últimos años (que son innumerables).

1 Una de las cosas que más me extraña de la carrera hacia Canvas+JavaScript es que todavía no he oído de nadie que se esté preocupando de crear herramientas de autor (no necesariamente un Flash, quizás más algo en la línea de Authorware, del jurásico AmigaVision o del silúrico HyperCard). Me da a mí que ahí hay una gran oportunidad de negocio. Adobe tardará entre año y medio y dos años en poner en marcha CS6 y aún van a ser los primeros en llegar al mercado…

Anotar PDFs con el iRex Digital Reader 1000

Foto de un IRex DR1000
Un cacharrito interesante. Foto de Marcel030NL. Click en la foto para acceder a su cuenta de Flickr

Me van a disculpar una entrada que es más que nada un ‘recordatorio para mí mismo’…

Resulta ser que hace unos meses me compré un IREX Digital Reader 1000, un lector de libros electrónicos no ausente de defectos (comenzando por el precio y siguiendo por la vida de la batería, que podrían ser mucho mejores), pero que tiene sus ‘hechos diferenciales’. Principalmente,

  • una pantalla de 10,2″ y resolución 1024×1280 que permite leer un PDF DIN A4 sin dejarse los ojos en el intento, y
  • un sensor Wacom que permite anotar documentos.

La combinación de ambos puntos lo convierte en maná del cielo para quien, como el que suscribe, se ve de vez en cuando en la necesidad de revisar ingentes cantidades de papel (pesa menos de 600 gramos, una hoja DIN A4 algo menos de 5 gramos, con lo que a partir de 120 hojas, gana el cacharro, por goleada si, pongamos por caso, había que cargar con un paquete de 500…).

El problema (siempre tiene que haber un problema, ¿verdad?) es que cuando uno anota un PDF, el cacharrito, en lugar de montar las anotaciones sobre el PDF, las guarda en un archivito ‘metadata.db’. Algo que, en un principio, está muy bien, puesto que conserva la integridad del documento original. Estaría mejor, claro, si hubiese un método fácil y evidente de generar un PDF que combinase original y anotaciones…

Y existe un método fácil. Y a lo mejor es evidente, pero al menos a mí no me lo parece. Y es que si con el software del cacharro le decimos que haga un ‘merge’ de un documento anotado… nos envía a tomar viento. ¿El ‘camino alternativo’? En el PC, y antes de anotar el documento (documento.pdf, pongamos por caso), le decimos al software que lo queremos ‘convert to template’. Al abrir el documento desde el cacharro, nos generará un nuevo PDF, documento_001.pdf. Al abrirlo desde el ordenador seguirá sin tener nuestras anotaciones, pero, si ahora le damos al botoncito Merge nos generará un tercer PDF, documento_001_Merged.pdf que, finalmente, contendrá nuestras anotaciones.

Retorcido, lo sé. E innecesario, tremendamente innecesario. Pero funciona…

Si alguien conoce un método mejor, ya tarda en dejar el correspondiente comentario :-).

Un píxel ya no es lo que era

Una de las cosas complicadas de colocar cosas en una pantalla es que hace tiempo que dejamos de saber a priori qué tamaño físico tiene esa pantalla, ni la ratio (¿4:3, 16:9, 16:10, 2.35:1?) ni cuántos píxeles tenemos a mano (ni, por tanto, la densidad de esos píxeles en pantalla, que hoy en día puede ir de algo más de 100 para una pantalla de ordenador a más de 200 en algunos dispositivos móviles).

Parece ser que el hecho de que esto sea así desde hace tiempo no ha evitado que cobre especial atención ahora por el rumor de que la próxima iteración de hardware del iPhone se va a ir a unos muy espectaculares 960×480 píxeles, lo que ha hecho que, naturalmente, se inquieten los desarrolladores, tanto web como de aplicaciones nativas, que obviamente no quieren que sus aplicaciones se encojan hasta niveles ridículos en una pantalla muy grande. Es fácil suponer que Apple no va a meter la pata con una cosa así, pero me ha llevado a QuirksBlog, que le dedica una entrada al tema, A pixel is not a pixel is not a pixel que habla, a su vez, de la solución que tiene Android para el tema (la diversidad de pantallas de los dispositivos Android provoca vértigo y, en más ocasiones de las deseables, nauseas…). Copio-y-traduzco de la página de soporte para múltiples pantallas:

Density-independent pixel (dip)

Una unidad de píxel virtual que pueden utilizar las aplicaciones para definir su IU para expresar dimensiones de ‘layout’ o posicionado independientemente de la densidad.

El píxel independiente de densidad es equivalente a un píxel físico en una pantalla de 160 ppp, la densidad base asumida por la plataforma […]. Se recomienda fuertemente usar unidades dip para definir la IU de la aplicación, como forma de asegurar una buena presentación de la IU en diferentes pantallas.

Cosas veredes, Sancho…

¿Muchas pestañas abiertas en Firefox? Quizá te interese BarTab

Si estás leyendo con Firefox, levanta la vista y cuenta cuántas pestañas tienes abiertas. Si hay menos de cuatro, muy probablemente no te interese BarTab. Pero si hay 8 o 10, y cuando cierras le dices a Firefox que te las guarde para el día siguiente, probablemente sí te interese… Porque mañana, cuando abras el navegador de nuevo, Firefox se pasará un minuto cargando pestañas que no vas a leer hasta dentro de unas horas (o días). Y esa es una de las cosas que te permite evitar BarTab. Sus funcionalidades:

  • al iniciar sesión, no cargar automáticamente todas las pestañas que dejaste abiertas al cerrar;
  • no cargar automáticamente un enlace que abrimos en pestaña nueva
  • o descargar las pestañas a las que no hemos accedido en un periodo de tiempo predeterminado (útil, sobre todo, en sistemas con memoria limitada).

Cada una de ellas activable por separado. Las pestañas ‘descargadas’ se cargan automáticamente al hacer clic sobre ellas, con un ‘delay‘ configurable, si se desea.

Lo sé, no le será útil a la inmensa mayoría, pero estoy convencido que los cuatro a los que les solucione un problema lo agradecerán.