Mes: agosto 2010

  • javascript supervitaminado

    En mozilla hacks nos han mostrado un par de ejemplos que demuestran la mejora de velocidad de Firefox 4, que se debe (entre otras cosas) a un nuevo motor de javascript llamado JaegerMonkey. Éste motor intenta aunar lo mejor de dos técnicas para acelerar la compilación en tiempo real: basada en trazas (tracer JIT) y en métodos (method JIT). El compilador basado en trazas es mucho más rápido que los compiladores basados en métodos, pero es una técnica que no siempre se puede aplicar, por lo que en media es más lento. La versión actual de Firefox utiliza el tracer JIT y es más lento que los compiladores de Chrome y Safari que utilizan method JIT. Para no alejarse del rendimiento de Chrome y Safari, los chicos de Firefox han decidido crear JaegerMonkey, un compilador nuevo basado en métodos al que esperan añadirle compilación basada en trazas para mejorar el rendimiento. Tienen incluso una página, are we fast yet, en la que muestran el progreso en la mejora de rendimiento, que se va acercando poco a poco a la velocidad de Chrome y Safari.

    Las optimizaciones en el motor de javascript son a bajo nivel, con código muy pegado a la máquina. Estas mejoras ayudarán a los desarrolladores y permitirán aplicaciones web mucho más rápidas y potentes con una ejecución lo suficientemente rápida cómo para que no haya diferencias significativas con las aplicaciones de escritorio. En los ejemplos de mozilla hacks muestran un editor de imágenes y una FFT aplicada en tiempo real a un video. Todavía no son comparables a las aplicaciones de escritorio comparables, pero son aplicaciones impensables hace unos años en javascript.

  • como cambian las cosas

    La guerra de los navegadores que enfrentó en los 90 a Netscape con Explorer de Microsoft terminó con un navegador predominante que no era compatible con los estándares de la web. Desde entonces pesar de que explorer es el navegador más utilizado, ha estado por detrás en características y compatibilidad, llegandose a la situación de que Explorer durante muchos años era el estándar de facto frente a las especificaciones del w3c (el consorcio que se encarga de definir los estándares de la web).

    En la segunda guerra de los navegadores, que empezó cuando mozilla empezó a desarrollar su navegador firefox, microsoft ha seguido rezagada en compatibilidad y características. Explorer es el único navegador que no soporta muchas características de html5 y css3, mientras que firefox, chrome, safari y opera ya soportan una buena parte de los nuevos estándares.

    Pero al fin, microsoft parece que se preocupa de los estándares: han creado un concurso de aplicaciones web de menos 10K en el que uno de los requisitos es que la aplicación funcione con Firefox, Webkit (Chrome y Safari) y IE9 dev preview (la nueva versión de internet explorer en desarrollo). Recuerda mucho a chrome experiments, pero hace más enfasis en la compatibilidad entre navegadores, impensable hace unos años.

  • la web ha muerto

    Chris Anderson (famoso por su teoría de la larga cola) y Michael Wolff han levantado la polémica entre los bloggers con un artículo en wired en el que declaran que la web ha muerto. Según su punto de vista, la web ha muerto básicamente porque cada vez se accede menos a las aplicaciones online a través de un navegador y cada vez se usan más aplicaciones específicas para iPhone o iPad.

    Uno de los problemas del artículo es haber utilizado un gráfico de Cisco para apoyar su teoría, por lo que se les ha criticado duramente:

    • El gráfico muestra la cantidad de tráfico, el video consume mucho más tráfico que la web.
    • En la etiqueta video está incluido el video a través de la web (video a través de flash en sitios cómo youtube). Técnicamente se usa un navegador web para acceder a ese video.
    • La medida en tráfico no es comparable a la medida en tiempo de uso. La gráfica mide ancho de banda consumido porque a Cisco es un dato que le interesa para optimizar sus routers, pero es complicado extrapolar que la web ha muerto a partir de éste gráfico.
    • En su razonamiento exageran el peso de las aplicaciones de iPhone y iPad. Comparado con el total de consumo de datos no creo que sean muy relevantes, aunque probablemente dominen en sus respectivos mercados.

    Sin embargo sus comentarios tienen cierto sentido, puede que se esté iniciando un cambio de tendencia:

    • Las aplicaciones en iPhone y iPad son (en general) más fáciles de usar que las páginas web. El navegador supone un añadido sobre las aplicaciones web  que complica su uso.
    • Google va a abrir una tienda de aplicaciones, cada vez más usuarios utilizan esta forma para buscar e instalar aplicaciones nativas y a partir de que google abrá su tienda también web. Es una forma de ocultar el navegador y esconder su complejidad, ya que permitirá instalar aplicaciones web.
    • Para los desarrolladores es una forma más fácil de monetizar una aplicación que la publicidad, por lo que habrá dinero corriendo y negocio, al igual que la App Store de Apple.

    Creo que no han tenido en cuenta en escenario que en mi opinión más probable: el navegador es cada vez más un elemento que no aporta nada al usuario, que quiere acceder a aplicaciones web. Sin embargo es un elemento casi imprescindible para la arquitectura actual de aplicaciones web, así que lo más probable es que el navegador se integre en el sistema operativo. Google va a tratar de conseguirlo a través de Chrome OS. Uno de los principios descritos en The Laws of Simplicity de Jonh Maeda es el de ocultar la complejidad. Así cómo google es una caja de búsqueda sencilla que oculta miles de servidores y protocolos complejos, el navegador es un elemento complejo que, cada vez más, sólo sirve para acceder a aplicaciones web.

    Por otra parte la web se apoya en el protocolo HTTP y muchos aplicaciones aunque sean nativas seguiran usando el protocolo de la web para acceder a la información. Así que  técnicamente la web sigue funcionando aunque sea por detrás. Por ejemplo TeetDeck, es una aplicación nativa, pero se apoya en el api de twitter basado en http.

    En definitiva, a los usuarios les dará igual cómo acceder a internet, sea a través de un navegador o una aplicación nativa. En un estudio de hace tiempo, la mayoría de usuarios ni si quiera sabían lo que era un navegador. Las aplicaciones que usen internet se construirán a base de aplicaciones web ó nativas pero en cualquier caso la web no morirá sino que probablemente se transformará y el navegador quedará oculto en la tripas del sistema operativo.

  • watson

    Hace unos meses (aunque yo me he enterado por el radar de O’Reilly hace unos días y en sinapsis tienen un artículo muy completo), IBM presentó a Watson, un sistema de procesamiento de lenguaje natural pensado para participar en el concurso de preguntas y respuestas Jeopardy! Al igual que con la victoria de Deep Blue en ajedrez, IBM busca superar un reto en el que vencer a los humanos en tareas inalcanzables (por ahora) para los ordenadores. El video es muy bueno:

    Algunas ideas que se me ocurren sobre Watson:

    • Procesa lenguaje natural escrito: No sólo procesa el lenguaje de manera estadística o semántica, sino que un concurso cómo Jeopardy! requiere que Watson sea capaz de comprender juegos de palabras, información omitida, dobles sentidos… Lenguaje en la forma más humana (e incomprensible para las máquinas actuales).
    • Agrupa múltiples paradigmas/tecnologías: Creo que alguna vez lo he comentado, mi opinión es que no se puede utilizar un sólo enfoque para crear un sistema de inteligencia artificial, a menos que esté dedicado a un problema muy concreto. En este caso, Watson integra las tecnologías de procesamiento de lenguaje natural, recuperación de información, representación del conocimiento y aprendizaje automático.
    • Utiliza varios algoritmos simultáneamente: no sólo agrupa varias tecnologías, sino que para hacer búsquedas utiliza varios algoritmos de búsqueda de información y los integra para calcular un valor de confianza en la respuesta. Si con el algoritmo X cálcula que una respuesta tiene un 50% de ser cierta y el algoritmo Y corrobora la respuesta, entonces la confianza en la respuesta aumenta.
    • Cálculo de confianza: Es el algoritmo fundamental de éste sistema. Tiene pinta de estar basado en cálculos probabilísticos complejos, diría que es donde más han trabajado y dónde los algoritmos de aprendizaje tienen más margen para funcionar. El hecho de que sea estadístico es también muy importante: demuestra que no es necesario que un ordenador tenga un pensamiento binario y le aporta cierta capacidad de fallo «discontinuo» más parecido al razonamiento humano.
    • Tiene problemas con las frases de doble sentido: es lógico que sea así, es la parte que peor procesa un ordenador. Cómo se ven en el video,  lo peor no es que se equivoque en la respuesta sino que se equivoque en el sentido de la respuesta: que le pregunten por una persona y conteste con el título de una película.
    • Test de Turing: es capaz de engañar a las personas. En muchos sitios los comentarios eran exagerados, cómo si Watson fuese capaz de mantener una conversación en lenguaje natural. Aunque el presentador lee la pregunta, a Watson le llega por escrito. Por otra parte es sorprendente el efecto sobre los concursantes humanos, se sienten amenzados (Humans! grita un concursante) y despierta un orgullo de defensa de la humanidad (cómo si Watson no fuese una creación humana que se apaga desconectando un botón).
    • Test de Turing(2): Si no está seguro de una respuesta, no contesta. En este caso se trata de una estrategia para ganar el juego, pero también supone una imitación del comportamiento humano. Es el tema del artículo de Mike Loukides, que el Test de Turing no consiste en demostrar que una máquina es inteligente sino que es inteligente en el sentido humano, incluyendo sus fallos. Por ahora no es así, cómo demuestra el tipo de errores que Watson comete. No son los fallos que comete una persona.
    • Utiliza uima de apache: una arquitectura open source para el procesamiento de información no estructurada. Aunque no vayan a liberar el código fuente, es importante que se utilicen plataformas open source, garantiza que al menos una parte del trabajo se compartirá.
    (por ahora)
  • ¿qué empresas necesitan buenos «hackers»?

    Impresionante ensayo de Paul Graham del que he extraido y traducido (con ayuda google, no es una traducción perfecta) algunas reflexiones. Yahoo tenía el potencial para convertirse en lo que ahora es Google pero, a pesar del éxito pasado, está cayendo en desgracia. Según Graham, el fracaso se debe a que Yahoo no tenía a los mejores hackers dentro de la empresa. Se dejaron llevar por el dinero fácil obtenido por los banners publicitarios y no invirtieron en software de calidad:

    The worst consequence of trying to be a media company was that they didn’t take programming seriously enough. Microsoft (back in the day), Google, and Facebook have all had hacker-centric cultures. But Yahoo treated programming as a commodity. At Yahoo, user-facing software was controlled by product managers and designers. The job of programmers was just to take the work of the product managers and designers the final step, by translating it into code.

    One obvious result of this practice was that when Yahoo built things, they often weren’t very good. But that wasn’t the worst problem. The worst problem was that they hired bad programmers.

    La peor consecuencia de tratar de ser una empresa de medios fue que no se tomaron suficientemente en serio la programación. Microsoft (en su día), Google y Facebook han centrado su cultura empresarial en los hackers. Pero la programación en Yahoo era tratada como una mercancía. En Yahoo, el software diseñado para los usuarios era controlado por los jefes de producto y los diseñadores. El trabajo de los programadores era sólo para tomar el trabajo de los directores de producto y los diseñadores en la etapa final, para su traducción al código.

    Un resultado obvio de esta práctica era que las cosas que hacía Yahoo a menudo no eran muy buenas. Pero ese no fue el problema más grave. El peor problema fue que contrataron a malos programadores.

    Si el software supone una ventaja competitiva muy grande en una empresa, entonces la diferencia en tecnología es fundamental. Es España todavía no se comprende esto:

    So which companies need to have a hacker-centric culture? Which companies are «in the software business» in this respect? As Yahoo discovered, the area covered by this rule is bigger than most people realize. The answer is: any company that needs to have good software.

    ¿Qué empresas necesitan tener una cultura  centrada en los «hacker»? ¿Qué empresas están «en el negocio del software»? Como Yahoo descubrió, el área cubierta por esta regla es más grande de lo que la mayoría de la gente piensa. La respuesta es: cualquier empresa que necesite tener un buen software.

    Una visión muy personal sobre los problema de Yahoo, por parte de una de las personas que mejor conocen la empresa. Si pensamos en España la situación es muy parecida a la de Yahoo: las empresas tecnológicas en España son en muchos casos vendedoras de carne que tratan el software cómo una mercancía. Mientras sea más rentable sacar dinero de la carne que de vender productos tecnológicos, seguiremos tendiendo una industria cárnica de baja calidad (aunque aparentemente sean empresas tecnológicas de primera línea).