El -webkit-problema

El que confíe, espere y desee que algún día desarrollar para la web sea una tarea fácil porque sólo hay que comprobar las cosas en un pequeño número de circunstancias debería tener en cuenta que eso ya pasó una vez: cuando Internet Explorer 6 dominaba la Tierra. Que nadie se llame a engaño: cuando Explorer 6 salió al mercado (un 27 de agosto de 2001, no ha llovido…) fue lo mejor que le podía pasar a la web en aquel momento y, cuando un par de años más tarde alcanzó una cuota de mercado del 90%, diseñadores y desarrolladores web pudieron, por primera vez, vivir tranquilos con un navegador decente (para la época). Hoy sabemos que el monocultivo IE6, de hecho, ahorró bastante trabajo a corto plazo… y tuvo tantos efectos perniciosos para la web que hoy en día renegamos de él como si nunca debiese haber pasado (con bastante razón, además).

Un panorama muy Webkit

La situación actual, a primera vista, no tiene muchos puntos en común con la de principios de siglo, pero determinadas prácticas —y, sobre todo, el advenimiento imparable de la web móvil y el cambio de panorama que supone— nos están poniendo en una situación de riesgo que gira alrededor de Webkit, el motor que mueve a Chrome y Safari, principalmente, en el escritorio, pero sobre todo a los navegadores por defecto de iOS y Android. Por poner unos números (y dibujitos) al asunto, en enero de 2011, en este modesto blog estábamos así (disculpas por el uso de tartas, se aceptan sugerencias de mejora):

Un reparto no óptimo (sobre todo porque la cantidad de IE6 era no negligible), pero diverso. Pero si miramos el mismo reparto en los últimos 31 días, el vuelco ha sido más que notable:

Esa brutal subida de los navegadores Webkit tiene dos vectores principales: Chrome, por sus avances tecnológicos y la pasta en publicidad que se deja Google, por un lado, y los navegadores móviles, por el otro, como ya comentábamos.

No, no estamos como en 2001 o 2002: de momento la cosa es muchísimo más diversa y, además, no podemos acusar a Google ni a Apple (ni a Adobe, que también invierte lo suyo en el desarrollo de Webkit) de las prácticas monopolísticas que usó Microsoft en su momento. En ocasiones Google juega de manera discutible, al menos en mi opinión, pero es innegable que Webkit avanza más deprisa que Firefox y Opera (Microsoft es capítulo aparte) en bastantes aspectos relevantes (no todos, pero esa es otra historia). Si a eso le sumamos el músculo económico para el marketing del que disponen y la inteligencia que demuestran en usarlo, el resultado no es precisamente de extrañar.

Y luego queda, claro, el tema de la web móvil (y para otros dispositivos, como las teles “conectadas”, que cada día abundan más). Ahí el iPhone, el iPod, el iPad y todo el ecosistema Android han hecho maravillas por Webkit. Su dominio no es absoluto (de hecho, Statcounter afirma que Opera sigue siendo el navegador móvil más usado globalmente) pero sí lo es en mindshare: si alguien encarga una web y llega a preguntar por la posibilidad de consultarla desde el móvil lo más probable es que en su bolsillo haya un iPhone o, en su defecto, un móvil Android; en ambos casos, el navegador que usará para sus pruebas será Webkit.

-propiedades-avanzadas-css

Volvamos a los navegadores y su evolución. Ya hemos comentado en alguna ocasión por aquí (y no deja de ser una obviedad) que los comités son lentos. Los grupos de trabajo del W3C son incapaces de seguir el ritmo que marcan los navegadores (de hecho, tampoco es su cometido correr detrás de estos cual galgo tras liebre), especialmente en lo que respecta a los avances en la creación e implementación de nuevas propiedades CSS (ejemplos paradigmáticos: border-radius o gradient). Una vez constatado este punto, se hizo necesario establecer un mecanismo para que los diferentes motores puedan implementar nuevas características sin que todos muramos en el intento… y se llegá la [aparentemente inofensiva] idea de los prefijos de fabricante: si Webkit decide implementar border-radius experimentalmente, lo hace prefijando un -webkit-. Mozilla usa -moz-, Opera -o- y Microsoft -ms-. La idea es que, en algún momento, border-radius pasará a ser una propiedad estandarizada CSS y nos podremos olvidar de los dichosos prefijos (pensad que implementar cuatro propiedades con prefijo más la oficial es más bien incómodo…).

border-radius es un ejemplo en el que todo el mundo se pone de acuerdo más o menos rápida y eficientemente (y un caso en el que, de hecho, nos podríamos haber saltado el proceso de los prefijos). gradient es un ejemplo de lo que pasa cuando cada fabricante tiene sus propias ideas sobre cómo debería funcionar algo: si os pasáis por el Ultimate CSS Gradient Generator podréis comprobar que Microsoft usaba una sintaxis atroz para conseguirlo desde los tiempos de IE6, los Webkits usaban otra sintaxis no tan fea pero que tampoco era ninguna virguería, que Mozilla comenzó a usar una sintaxis algo más razonable con Firefox 3.6 y que, después, esta sintaxis la fueron adoptando sucesivamente Opera, Webkit a partir de una cierta versión (desde Chrome 10 y Safari 5.1), Microsoft con IE10 (el día que salga) y que ahora hasta al W3C le parece bien la sintaxis, con lo que deberíamos poder utilizarla, en los navegadores modernos, sin semejante pesadilla de prefijos…

border-radius, pues, demuestra la necesidad de este mecanismo para introducir, poco a poco, propiedades experimentales

¿Y el problema?

[Un buen trozo de lo que sigue sale, en gran parte, de Vendor Prefixes - about to go south, de Remy Sharp.]

El problema es múltiple. Resulta ser que, naturalmente, siempre hay un navegador que hace las cosas antes que los demás. Y que, además, ese navegador tiene la manía de ser Webkit y, por tanto, acostumbra a llegar al usuario con las marcas Safari y/o Chrome. Y que Firefox y Opera suelen llevar un retraso notable (a ver quién es el guapo que le aguanta el ritmo a Google + Apple + Adobe…). Y que Internet Explorer suele llegar a la fiesta cuando se ha largado hasta el personal de limpieza (estos no tienen la excusa de la falta de recursos, pero también lidian con sus problemas: si fuera por el equipo de desarrollo de IE la cosa sería diferente, pero los ciclos de Microsoft y las necesidades del soporte corporativo son un tema en el que mejor no entrar, si no es estrictamente necesario)…

En algún momento, además, las propiedades experimentales (con prefijo) deberían o bien dejar de existir porque se demuestran poco útiles o bien dejar de existir porque han pasado a ser de uso general y, por tanto, a implementarse sin prefijo. Esto es, que sí o sí, las propiedades experimentales deberían venir con fecha de caducidad, por un motivo u otro.

¿Qué pasa? Los diseñadores, natural y comprensiblemente, implementan las nuevas características que trae Webkit para mejorar sus diseños, tan pronto como les resultan útiles. No importa si uno es de la escuela hard boiled, si predica el progressive enhancement o si es fiel a la doctrina de la graceful degradation, se trata de una práctica extendida y aceptable y respetable… siempre que uno sea consciente de que se trata de propiedades experimentales. ¿Qué significa esto? Que mientras sólo Webkit tira de la propiedad, usamos -webkit-propiedad. Y al cabo de un tiempo, cuando Mozilla y Opera la implementan, añadimos las correspondientes -moz-propiedad y -o-propiedad. Si, por algún milagro, Microsoft finalmente hace lo propio antes de que llegue el W3C, añadimos la -ms-propiedad. Y cuando llega, parsimonioso como debe, el W3C, añadimos la propiedad… y con un poco de suerte, hasta vamos eliminando las propiedades con prefijo a medida que los navegadores anticuados van desapareciendo del mercado.

¿Da miedo el procedimiento del párrafo anterior? Si no miedo, como mínimo una inmensa pereza, ¿no? Si no disponemos de alguna manera automatizada de hacerlo (posibles herramientas son Prefixr o -prefix-free), y tenemos unos cuantos diseños que mantener, el trabajo es digno de Job (siempre he sospechado que Job, de hecho, era front end de profesión). El resultado es que todo el mundo (todos los buenos diseñadores, al menos) corre a implementar las -webkit-. Pero que con cada paso posterior se pierden muchos, muchísimos trabajos. Y no sólo trabajos de demostración, sino sitios en producción, que deberían dar la mejor experiencia posible a todos los usuarios, independientemente del navegador que estén usando en ese momento…

¿Es tan grave la cosa?

Depende del punto de vista, desde luego. Si eres desarrollador en Mozilla y Opera y te acabas de pasar una noche sin dormir para colar en la última release la propiedad CSS de moda, y luego resulta que la mayoría de diseños que la usan en en Webkit pasa de tu cara, tiene que doler mucho.

Pero hasta a los desarrolladores de Webkit les tiene que doler tener que mantener sus -webkit-propiedades en el código: si las quitan, sus navegadores “romperán” muchos sitios que ahora usan toda la potencia de CSS, pero al mantenerlas pierden un milisegundo por aquí, otro por allá… Poco, quizás, pero con la lucha por la velocidad entre navegadores (y la creciente complejidad de los diseños de las páginas), hasta la última centésima cuenta…

Y si eres un diseñador, el dolor de cabeza de seguir la carrera metro a metro y decidir en cada punto cuál es la menos mala de las soluciones tampoco acaba de ser el más deseable de los futuros…

La cosa ha llegado, en los últimos días, a que los no-webkit se planteen (públicamente, en las discusiones del correspondiente grupo de trabajo del W3C) dar soporte a las -webkit-propiedades en su código. Si somos benevolentes, un parche horroroso. Siendo muy estrictos, una vulneración durísima de todo el proceso de estandarización. En cualquier caso, un efecto no previsto y muy poco deseable del proceso de innovación de los navegadores… :-(

Esperemos que el curso de la cosa comience a corregirse. De otra forma, los resultados previsibles (soporte incompleto a navegadores que cumplen los estándares, código spaguetti por todos lados, ineficiencias a mansalva) van a complicar la vida de desarrolladores y usuarios. Poco a poquísimo, pero la situación se iría haciendo más y más insostenible con el tiempo.

Seguiremos informando.


Lecturas y recursos recomendados y recomendables

  • CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*
  • Vendor Prefixes – about to go south
  • WebKit Isn’t Breaking the Web. You Are
  • Los ya mencionados Prefixr y -prefix-free, más el imprescindible CSS3, please!
Más »

PowerTutor: ¿Quién se ha comido la batería de mi Android?

Es un hecho que no va a cambiar a corto o medio plazo, y casi seguro que tampoco a largo: Google no va a ejercer en el Market de Android el férreo control del que hace gala Apple en el Appstore de iOS. Eso tiene sus cosas buenas y sus cosas malas. Entre las malas está que se cuelan con una cierta frecuencia aplicaciones que no están todo lo bien programadas y diseñadas que deberían. A veces eso es obvio y lo único que pasa es que instalamos, probamos, nos horrorizamos y desinstalamos. Unos minutos perdidos, pero cosas peores nos han pasado a todos.

Pero otras veces los defectos no son obvios: es el caso de aplicaciones que consumen ingentes cantidades de recursos y se comen la batería del móvil. Android dispone de alguna herramienta básica para monitorizar ese uso de la batería, pero eso no es suficiente. Y ahí entra PowerTutor (web oficial, market), una aplicación gratuita que nos permite inspeccionar más a fondo a dónde ha ido a parar ese 100% de batería que teníamos hace un rato.

Una pantalla de 5.3" consume <strong>mucha</strong> energía

La vista inicial con la que nos saluda la aplicación es informativa (tener la pantalla encendida es caro…), pero no muy útil. Pero si accedemos a la vista de uso de energía por aplicación tendremos muchas más pistas:

Afortunadamente, en este caso no hay especialmente preocupante

Y es que en esta vista tenemos la información desglosada por aplicación pero, sobre todo, podemos contabilizar o no la energía dedicada a la pantalla, la CPU o las comunicaciones vía WiFi o 3G. Ya hemos visto antes que mantener la pantalla encendida es muy caro: si descontamos ese consumo nos será mucho más fácil ver qué aplicación está malgastando ciclos de CPU y, por tanto, gastando la batería inútilmente (y también podremos detectar, a veces, qué aplicaciones están usando 3G y/o WiFi cuando no deberían, aunque para eso hay aplicaciones específicas)…

De nada :-)

Más »

Los tuitlinks de la semana (31)

Ya os suena la cosa, ¿no? Los mejores enlaces aparecidos esta semana en mi cuenta de Twitter, @chechar. Esta vez la semana ha sido poco prolífica…

Los de desarrollo web

interesante: Mozilla developing Web push notification system for Firefox j.mp/wX8evy

el ‘customize and download’ de Bootstrap 2.0 (el framework CSS de twitter) es de ovación cerrada j.mp/zCwGMf

más ovaciones cerradas: las Developer Tools de Firefox siguen evolucionando j.mp/xhuz8f

Wireframing in Powerpoint? It Works! (UX Magazine) j.mp/xhqctC

Morphing particles j.mp/yhZb5W

2001 all over again: Internet Explorer 6 share grows (and Chrome falls) j.mp/zytp4e

Los de cacharritos

el iPhone representa el 75% del total de beneficios del mercado de móviles. #casiná j.mp/wFpZE9

twiteando en morse. pero de verdad j.mp/z5qZiI

Y el audiovisual…

The beautiful math behind the ugliest music (ojo: contiene Galois)

Más »

Primeros días con el Asus Transformer Prime

La familia crece...

Que no se diga que no hago lo suficiente por la causa Android: si hace nada hablaba del Woxter TV 100 que me acababa de comprar, hoy toca hacer lo propio con el Asus Transformer Prime, el enésimo cacharro con Android que me compro…

Para los que no hayan oído hablar del invento, se trata de un tableta Android (de fábrica sale con Gingerbread, pero ya está disponible la actualización a Ice Cream Sandwich, que se instala sin problemas) de 10.1″ (1280×800, Super IPS+) y 586 gramos de peso. El chipset es el Tegra 3 de Nvidia y tiene un giga de RAM. El almacenamiento interno es de 32 o 64 gigas, según modelos, con la posibilidad de añadir una tarjeta SD de hasta 32 gigas. Cuenta con dos cámaras, de 8 megapíxels por un lado y 1.2 por el otro y las especificaciones habituales de básicamente cualquier cacharro moderno que se precie, si bien cabe anotar que no cuenta con espacio para una SIM, por lo que sólo se conectará a la red vía los ya citados WiFi y Bluetooth.

¿Es una tableta? ¿Es un ordenador? Eso sí, más vale que os vayáis acostumbrando a las marcas de los dedos sobre la pantalla...

El “hecho diferencial” con la mayoría de tabletas del mercado es, naturalmente, la disponibilidad de un ‘teclado-dock’ que permite que esté escribiendo esta entrada en la propia tableta. Dock y tableta se conectan sin problemas y la combinación tiene el aspecto, a primera vista, de un “netbook” de 10″ cualquiera, hasta que uno se fija en que la fila del teclado de las teclas de función es diferente y que hay una profusión de teclas específicas Android (inicio, retroceso, búsqueda, menú, acceso a configuración). El teclado, por sí sólo, pesa unos bastante espectaculares 537 gramos, dejando el peso de la combinación en un pelo más de 1.1 kilos. Ese peso es casi obligado para que la tableta-pantalla no venza el conjunto hacia atrás y Asus aprovecha la necesidad de lastre para añadir una batería de 22 Wh que, sumada a la de la tableta, de 25 Wh, les permite anunciar una vida de batería para el conjunto de 18 horas. Sin haber puesto a prueba la afirmación, sí puedo adelantar que, a no ser que se le vaya a dar bastante caña, puede uno salir de casa por la mañana sin cargar con el alimentador y sin preocuparse por ello. Hablando del alimentador, tiene una salida USB convencional (por el lado de la tableta y el dock se trata de un conector propietario de Asus), pero en mi experiencia no carga ni enchufando la tableta (ni el dock) a un puerto USB alimentado de ordenador (he probado con un Mac y un PC) ni con el alimentador USB que uno usa para cargar el resto de aparatos USB que corren por casa. Por tanto, sí habrá que cargar con el alimentador si nos vamos más de un día (no es especialmente grande, todo sea dicho).

Mi opinión

Después de tres o cuatro días de uso irregular, estoy encantado con el cacharro. El netbook perfecto se parece mucho a esto: ligero, con un teclado aceptable (teclas de poco recorrido, puestos a criticar), vida de batería que te permite no pensar en buscar enchufes y procesador y RAM que van más allá de lo que les exige el sistema operativo, más la gozada que representa poder interactuar poniendo los dedazos en la pantalla (primero, porque la pantalla es táctil, pero después porque tanto el sistema operativo como las aplicaciones han sido pensados para ello).

Añado que yo había anticipado que la tableta, por mi uso, viviría casi siempre pegada al teclado, pero me equivocaba: la facilidad de unir y separar las dos piezas del puzzle hace que lo hagas con frecuencia: si sólo consumes información, separas el teclado. Si, de golpe, recibes un correo que requiere de una respuesta de más de una línea, estiras el brazo, coges el teclado, lo montas y te pasas inmediatamente al modo netbook. El nombre de Transformer, con el permiso del propietario de la marca, es realmente merecido.

Y no quiero dejar de comentar la sonrisa que provoca tener la combinación desenchufada de la pared pero que la tableta te diga que se está cargando desde el teclado, o la posibilidad de dejar el teclado cargándose mientras uno se da una vuelta por ahí con la tableta :-).

Los problemas

Haberlos haylos. Que esté encantado no quiere decir que todo sea perfecto. Como siempre, cuando hablamos de un dispositivo Android, no queda más remedio que compararlo contra el lado iOS de la ecuación (o de la inecuación, mejor). Y como siempre, acabamos hablando de la fragmentación de Android que, en este caso, es tanto una bendición como una maldición. Bendición, para comenzar, porque un híbrido tableta-netbook como este difícilmente va a existir jamás en el lado Apple. Y para los que queremos ese híbrido, la discusión se para aquí. O Android o Android o Android. Pero eso no evita que la fragmentación comporte también dos inconvenientes insalvables. Por un lado, el ecosistema de accesorios jamás va a ser como el del iPad (a no ser que haya una estandarizacción más que improbable entre fabricantes rivales o que, al más puro estilo Inmortales, al final sólo quede uno). Por el otro, diseñar interfaces que funcionen como dios manda sobre la infinita variedad de dispositivos Android es una pesadilla que no se ha resuelto y que difícilmente lo va a hacer a corto o medio plazo.

En el caso de las tabletas Android se suma, además, el problema que tuvo el iPad al principio: de momento, la mayoría de aplicaciones está pensada para correr en un dispositivo de unas 4″, no 10″. Y eso se nota muchísimo. Muchos de los desarrolladores de los que uno esperaría que fuesen en cabeza en la carrera por conquistar las tabletas Android no cuentan todavía con aplicaciones adaptadas al nuevo y “enorme” tamaño de pantalla (Facebook sería el ejemplo paradigmático: su aplicación, especialmente en modo ‘landscape’, es un océano blanco que te hace pensar que mejor tirar del navegador y la interfaz “de toda la vida”).

La tableta detecta las aplicaciones que no responden al tamaño de pantalla y nos da a elegir entre hacer un zoom a lo bestia (que sólo me parece útil si uno tiene problemas de visión importantes) o de forzarla al nuevo tamaño de pantalla, dando lugar a los mares de blanco que comentaba antes. No se me ocurre por qué no nos da la opción, por ejemplo, de dividir la pantalla en, pongamos por caso, tres espacios 420×800 y dejar que las aplicaciones corran allí, o incluso en pseudoventanas sobre el escritorio…

Con las tabletas con Android 4.0 debemos añadir, además, la novedad de dicha versión del sistema operativo: mucho desarrollador aún no ha testeado sus aplicaciones contra él, y eso provoca defectos de jueventud que uno no esperaría de aplicaciones que ya llevan una buena temporada circulando (a Firefox, por ejemplo, se le atragantan los textos con acentos, cosa que hace que su uso sea bastante intolerable, y resulta menos explicable que la aplicación de Reader tenga la molesta manía de colgarse de vez en cuando mientras está corriendo de fondo).

Como podéis observar, mis problemas son más inherentes a la plataforma y sus características que otra cosa. Sí querría comentar tres aspectos específicas de Asus que no me acaban de convencer. El primero, la decisión de pasar del conector HDMI del Transformer al micro HDMI del Transformer Prime. Sí, el conector es más pequeño y da la misma funcionalidad, pero encontrar un cable micro HDMI no es trivial, ahora mismo, y si uno va con prisas puede hacer que acabes pagando un precio bastante exorbitante por él. En segundo lugar, aún no tengo muy claro por qué incluir el touchpad en el teclado-dock: el mío lleva un par de días desactivado, dado que (i) es fácil interactuar directamente con la pantalla y pasar de él, (ii) es demasiado pequeño como para resultar verdaderamente útil y (iii) uno corre el riesgo constante de activarlo inadvertidamente mientras teclea, con efectos potencialmente peligrosos… Se me antoja que se podría haber eliminado sin demasiados problemas o, en su defecto, haberlo sustituido por un puntero al estilo Thinkpad. Y, finalmente, una de las críticas que se repiten casi unánimemente al hablar del Prime es que sabemos que dentro hay un GPS, pero parece que el diseño del aparato dificulta su funcionamiento de tal manera que es como si no estuviese. DIgo yo que, ya puestos, se/nos lo podrían haber ahorrado.

La carta a los Reyes

¿Qué le falta al Prime para ser perfecto? Obviando los temas del tocuhpad y el conector micro HDMI, falta, sobre todo, madurez del software y la aparición o evolución de aplicaciones que se adapten a la experiencia de las 10″. Falta, también, que aparezca una aplicación ‘Office’ que exprima realmente las posibilidades de esta nueva generación de Androids (parece que QuickOffice es algo mejor que Polaris, que Asus incluye con la tableta, LibreOffice dice que está trabajando en migrar su suite a Android y, poco a poco Google Docs va mejorando y convirtiéndose en una solución viable, aunque aún le falta la edición offline de documentos, por ejemplo). Y… Y poca cosa más, en mi humilde opinión. Insisto en que, al menos de momento, mi satisfacción es muy grande con la nueva adquisición.

¿Dudas? ¿Curiosidades?Para esto tenéis los comentarios :-).

Más »

Los tuitlinks de la semana (30, edición ‘jumbo’)

Después de un fin de semana de no recoger los mejores enlaces aparecidos por @chechar, se nos ha acumulado un poco…

Los de diseño y desarrollo web

Mon Dieu! Sir Tim Berners-Lee created the web in France, not Switzerland j.mp/wXxhQT

HTML5 Cross Browser Polyfills. The All-In-One Entirely-Not-Alphabetical No-Bullshit Guide to HTML5 Fallbacks j.mp/wIqbvV

video.js. vídeo html con ‘fallback’ a flash j.mp/wWYRpu

#interfaces *muy* interesante, *muy* de acuerdo: Bring Back the Stylus! j.mp/wYwNKz

otro gran recurso #webdev: css3clickchart.com/

y otro más: docs de HTML, CSS JS y el DOM (de la MDN) y jQuery y PHP (oficiales), bien indexadas… dochub.io/

#infoviz Rickshaw: A JavaScript toolkit for creating interactive time series graphs j.mp/whPHAl

curso rápido HTML5 (HTML, CSS, etiquetas específicas, Canvas) de Microsoft, en castellano, vía @genbetadev j.mp/yb43S2

RT @brucel Confused about which #HTML5/CSS3/etc features to use? When to use polyfills? html5please.us is here to help! via @paul_irish

MUY de acuerdo #webdev #ibooks2 We need a standard zipped HTML file format j.mp/yClIgx

Ojo al cambio en el algoritmo… Official Google Webmaster Central Blog: Page layout algorithm improvement j.mp/AtnfMd

Nokia tiene un mapamundi en webgl… j.mp/zonds3

un repaso a las posibles alternativas para tablas HTML+CSS ‘responsive’ j.mp/zbCka4

mobilewebbestpractices.com/

Los tecnológicos

#molamazo Kinect and Windows Phone combine to create holographic game engine j.mp/wX1Hrf

#technostalgia Neo Geo! j.mp/zOUrFN

desde las primeras herramientas de cálculo hasta los ordenadores actuales, en dos minutos… j.mp/w2kFOA

RT @brucel RT @lturrentine: 4K of IBM memory found in my grandpa’s pole barn, captured in a 692K photo. bit.ly/w3BunI via @simonstl

How Google Spawned The 384-Chip Server j.mp/wmxN5X

Tom Bissell on the making of ‘Madden NFL’ (probablemente la mayor franquicia de videojuegos de la historia) j.mp/A7pnPB

#longreads Sobre el futuro de YouTube y los contenidos de vídeo para consumo ¿masivo? Streaming Dreams j.mp/xItUL0

Doom (el juego, sí) para calculadoras científicas. viva la ley de Moore j.mp/yVPA0z

Dos de visualización

arte + visualización j.mp/yv580A

RT @mathtourist: Visualizing Classical Music as a Roller Coaster Ride – The Atlantic bit.ly/zjUXvi

De propiedad intelectual…

de arte y apropiación… y los problemas que conlleva para la propiedad intelectual. en el NYT j.mp/A7a2YQ

Why the feds smashed Megaupload. de Ars Technica, que no es exactamente ‘pro big content’ j.mp/yGIp8s

Coincido prácticamente al 100%: El cierre de Megaupload en un campo que puede tener puertas www.error500.net/articulo/el-cierre-megaupload-en-un-campo-que-puede-tener-puertas

The Cost of Knowledge. Researchers taking a stand against Elsevier. #openaccess j.mp/w8GCDn

#openaccess :-) The Royal Society opens up permanently j.mp/wpANF4

Y el visual para cerrar

RT @esenabre Recordando esa Rapsodia Húngara nº 2 de Liszt interpretada por Tom & Jerry

Más »
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.