Mostrando entradas con la etiqueta google. Mostrar todas las entradas
Mostrando entradas con la etiqueta google. Mostrar todas las entradas

lunes, 11 de noviembre de 2013

Gigantes investigando: un vistazo al futuro

Research

Creo que por acá todos saben que las empresas más grandes en la industria del software no paran de investigar, a ver quién gana en el próximo salto tecnológico, o quien se asegura un par de patentes que les de ventaja en el mercado los próximos años.

Más allá de que estemos de acuerdo o no con la política alrededor de la propiedad intelectual, es interesante echar una mirada a lo que están haciendo algunos de los principales centros de investigación de los gigantes de la industria. Gracias a la gente de Y Combinator, les dejo una serie de links a las páginas principales  sobre el tema:

  • Microsoft Research y sus publicaciones
    Sus áreas de investigación cubren Comunicaciones y colaboración, Lingüistica computacional, Ciencias de la computación, Sistemas y Redes, Economía y Computación, Educación, Juegos, Gráficos y Multimedia, Hardware y Dispositivos, Salud y Bienestar, Interacción entre Computadoras y Humanos, Recuperación y Administración de Información, Aprendizaje Mecánico, Seguridad y Provacidad, Ciencias Sociales, Desarrollo de Software, Teoría y otras áreas temáticas.
     
  • Research at Google y sus publicaciones
    Cubren Algoritmos y Teoría, Inteligencia Artificial y Aprendizaje Mecánico, Administración de Datos, Minería de Datos, Sistemas Distribuidos y Computación Paralela, Economía y Comercio Electrónico, Innovación en Educación, Ciencia General, Hardware y Arquitectura, Interacción entre Humanos y Computadoras y Visualización, Recuperación de Información y la Web, Percepción Mecánica, Traducción Mecánica, Sistemas Móviles, Procesamiento de Lenguaje Natural, Redes, Seguridad, Criptografía y Privacidad, Ingeniería de Software, Sistemas de Software y Procesamiento del Habla.

  • IBM Research y sus publicaciones
    Uno de los pioneros en investigación de todo tipo, con más de 60 años en el tema y varios premios nobel a cuestas, cubren de todo, desde exploración y control espacial, genética y genómica, láseres industriales y quirúrgicos, salud, minería y por supuesto casi todas las áreas de software y hardware.
     
  • Yahoo! Labs y sus publicaciones
    El menor de la serie, tal vez por ser la empresa que tiene hoy más problemas de crecimiento y subsistencia, de todas maneras se mantiene activa en áreas como Publicidad Computacional, Interacción entre Humanos y Computadoras, Medios, Aprendizaje Mecánico, Movilidad, Personalización, Investigación de Sistemas, y Búsqueda y Minería Web.

Les dejo un par de videos sobre los dos primeros, para darse una idea del estilo.

Research at Google (~3 min):

  
y un Tour por Microsoft Research (~10 min):

martes, 8 de octubre de 2013

La era de las interfaces aéreas

Desde hace un tiempo vemos cómo las interfaces empiezan a alejarse del mouse, el teclado y últimamente las pantallas.

Mientras que todavía estamos tratando de optimizar al máximo las interfaces táctiles, seguimos teniendo montones de casos en los que lo ideal sería no tener que tocar la pantalla u otro dispositivo. Por ejemplo, en situaciones en las que estamos a cierta distancia de la computadora, o cuando tenemos las manos ocupadas en otras cosa, o sucias (cocinando, reparando un auto, o en medio de una cirugía, por ejemplo).

Kinect

Primero fue Xbox y su accesorio Kinect, uno de los desarrollos más revolucionarios salidos de Microsoft últimamente, que aunque arrancó más orientado al mercado de juegos, pronto agregó una edición para Windows, con su correspondiente SDK, abriendo el dispositivo a lo que que nuestras mentes quieran hackear.

Kinect utiliza una combinación de sensores y un láser infrarrojo que brinda datos de posicionamiento de objetos en 3D. Básicamente, tiene cámaras HD normales e infrarrojas, con lo que consigue no solamente una imagen plana, sino información de distancia. A esto se le suma una serie de micrófonos y una buena cantidad de software.

El SDK para Windows tiene un par de maneras principales de programar: la primera es manipulando los datos en crudo, con el nivel de complejidad que implica, y la segunda es usando un API de más alto nivel que básicamente rastrea posiciones del esqueleto de hasta dos personas simultáneamente. De esta manera se puede programar a más alto nivel, siguiendo el posicionamiento de manos, cabeza, rodillas, etc. Kinect no es muy fuerte aún en reconocimiento de dedos individuales, ni está pensado inicialmente para estar a corta distancia.

 

Leap Motion

Más recientemente se agregó a la partida Leap Motion, un dispositivo mínimo (ver foto), más chico que un teléfono convencional, tal vez un poco más alto. Se conecta por USB a una PC o Mac, y debe ubicarse entre nosotros y el teclado o el trackpad, básicamente bajo el área donde vamos a mover las manos.

La cajita contiene dos cámaras infrarrojas monocromáticas en conjunto con tres LEDs infrarrojos para lograr unos 300 cuadros por segundo a una resolución altísima, y es procesada por software propietario en el mismo dispositivo para proporcionar información de posicionamiento de los dedos muy detallada. Incluso permite detectar cosas como un lápiz en nuestra mano, y utilizarlo para dibujar sin necesidad de tocar la pantalla.

Leap Motion también provee un SDK con lo que pueden desarrollarse aplicaciones que exploten todo es potencial, que en principio es mucho mayor para aplicaciones de precisión, y como medio de interactuar con nuestra computadoras personales.

 

Flutter

Y ahora llega Flutter, recientemente adquirido por Google, y disponible para OS X y Windows, con la particularidad de que no requiere ningún dispositivo externo. Solamente utiliza la cámara incorporada en las notebooks, y detecta (por ahora) unos pocos gestos, orientados en principio a controlar reproductores de media como iTunes, VLC y unos cuantos más que van sumándose, incluyendo ahora algunos sitios como Grooveshark o YouTube, utilizando una extensión de Chrome.

Los gestos que reconoce por ahora son mano abierta para detener o continuar, pulgar a un lado o a otro para ir al track siguiente o al anterior, pero prometen algunos más.

Lo que todavía no está anunciado es un SDK o API para programar sobre el análisis que ellos ya realizan sobre la imagen, pero ahora que Google ha tomado el control, no cuesta mucho pensar en que se integre como funcionalidad básica de Chrome, y porque no, se abra a más usos.

 

Finalmente, para mi lo que queda esperar es más sensores del estilo de Leap Motion integrados directamente en una próxima generación de notebooks, tabletas y teléfonos (hay algunos de Smasung que reconocen ya algunos gestos básicos sin tocar la pantalla) y sobre todo, la aparición de capas de software que realicen la mayor parte de las transformaciones matemáticas necesarias para que podamos luego programar a más alto nivel.

martes, 17 de julio de 2012

El navegador que nos ayuda

Chrome

Hace poco mi colega Diego Marcet escribió un tweet que me hizo redescubrir, en toda su gloria, más características de Chrome que son geniales para los desarrolladores.

Tenía presentes algunas utilidades de Chrome como: chrome://net-internals/ (obviamente estos links sólo funcionan en Chrome), o chrome://dns/, pero Dieguito mencionaba que hay una URL genérica que muestra todos, y no conocía:

chrome://about/

Que muestra la siguiente lista:

List of Chrome URLs

For Debug

The following pages are for debugging purposes only. Because they crash or hang the renderer, they're not linked directly; you can type them into the address bar if you need them.

  • chrome://crash
  • chrome://kill
  • chrome://hang
  • chrome://shorthang
  • chrome://gpuclean
  • chrome://gpucrash
  • chrome://gpuhang

Todas estas herramientas son excelentes a la hora de diagnosticar y hacer pruebas en aplicaciones o servicios web, dándonos montones de detalles sobre el contenido de los mensajes HTTP, sino también sobre las interacciones, tiempos, efectos de cache, dns, pre-fetching, y muchísimas otras variables que afectan notablemente el tiempo de respuesta y hasta el funcionamiento de nuestros desarrollos.

jueves, 29 de diciembre de 2011

El año del código abierto para .NET (+video: .NET en Chrome!)

OuterCurve Foundation

Se va terminando el año 2011 y mirando hacia atrás desde la perspectiva de la comunidad .NET somos varios los que vemos que este año fue sumamente importante para el código abierto en ese entorno. Y no estoy hablando solamente de Microsoft, ya que .NET ya tiene entidad independiente de su creador original.

Para los que tienen ganas de leer posts más largos y en inglés, recomiendo los de Phil Haack (hasta hace poco líder del ASP.NET MVC en Microsoft, ahora trabajando para GitHub) y Miguel de Icaza (el incansable líder del proyecto Mono).

Este post es un resumen breve del contenido que ellos exponen, con algunas apreciaciones personales.

El modelo Open Source fue algo que Microsoft, con su tradición de secretos y licenciamiento complejo, tardó muchísimo en incorporar. Y más complejo aún el modelo de Free Software, que implica tanto apertura como gratuidad de los productos. Sin embargo, desde hace años, con pioneros como IronPython, el DLR, y más tarde ASP.NET MVC, varios productos de la plataforma de desarrollo empezaron a producirse bajo esta premisa. Un punto culminante de esta iniciativa fue en 2008, cuando Microsoft anunció que comenzaba a incluir jQuery en Visual Studio, colaborando con el proyecto (de manera abierta, como cualquier otro) e incluso brindando soporte sobre el mismo.

Al entender la importancia del movimiento, Microsoft finalmente generó una Fundación llamada OuterCurve (originalmente se llamaba CodePlex, pero usar el mismo nombre que su sitio de alojamiento de código resultaba muy confuso), que como la Fundación Apache, permite resguardar los derechos del código y de los autores en un ambiente controlado. Muchos proyectos hoy existen bajo OuterCurve, aunque hay muchos también directamente en Apache.

Finalmente, este año Microsoft avanzó más en ese sentido, mejorando notablemente las condiciones de búsqueda e integración de código abierto propio o de terceros, a través de NuGet, el administrador de versiones para .NET, inspirado en Ruby Gems y similares. NuGet se integra en Visual Studio o puede usarse en la línea de comando, y permite buscar en un catálogo muy abundante actualmente de componentes abiertos, instalarlos en nuestros proyectos, incluyendo todas sus dependencias, e incluso automatizar tareas relativas a su instalación y uso, como declararlos en configuraciones, generar código u otros artefactos desde la consola, etc. NuGet también facilita mantener actualizadas, si es necesario, todas las versiones de estos paquetes.

Pero como decía al principio, .NET va más allá de Microsoft (y de Windows) desde hace tiempo, y la alternativa principal es el proyecto Mono, que como Miguel comenta en su post, tuvo un año increíble, lleno de novedades. La más importante para el proyecto mismo fue la venta de Novell a Attachmate y el posterior corte del equipo completo de Mono, que rápidamente se reincorporó como Xamarin, un reflejo directo de Ximian, la compañía original de Miguel y Nat Friedman que Novell adquiriese años antes.

Más allá de la reagrupación, que no redujo en lo más mínimo el impulso del proyecto Mono, a pesar de que el equipo de Xamarin se concentró en poner en el mercado MonoTouch y Mono for Android (productos comerciales que les permiten seguir sobreviviendo). Mientras tanto, el equipo de Mono (que excede también a Xamarin, como todo gran proyecto abierto) entregó este año una avalancha de tecnologías (más allá de varias versiones del runtime mismo de Mono y de MonoDevelop, su IDE), incluyendo:

  • .NET en el navegador (al menos en Chrome) a través de Mono corriendo en el Native Client de Google. De hecho, Google mostró Mono en Chrome en un evento reciente, del que dejo el video al final de este post. Aunque el año pasado ya se podía programar en mono y utilizar el compilador estático para ejecutar código dentro de Chrome, este año ya se puede ejecutar el compilador a demanda (JIT) de Mono.
  • MonoMac es una extensión de Mono para programar aplicaciones para Mac OS X en .NET, incluyendo el soporte para Cocoa y todo el entorno del sistema operativo. Se programa utilizando MonoDevelop y algunas herramientas nativas como los diseñadores de XCode.
  • MonoGame (ya comentado antes en este blog) es un port del entorno de desarrollo de juegos XNA de Microsoft, pero abierto y con mayor alcance en plataformas.
  • Sony PlayStation Suite es un framework de Sony para desarrollar juegos en diferentes dispositivos de su línea, completamente basado en Mono.
  • Phalanger es un compilador de PHP, actualmente basado en Mono, utilizando el DLR, que además de ser el motor PHP de mayor rendimiento, permite extender ejecutar cualquier aplicación PHP y extenderla con librerías o aplicaciones .NET.
  • CXXI es una tecnología puente entre C# y C++ que permite ejecutar código de una a otra plataforma, pero también heredar clases entre ellas, sobre-escribiendo métodos o no, o llamando a la clase base, todo de manera muchísimo más sencilla, segura  y multi-plataforma que utilizando COM.
  • Y hay bastante más (ver el post de Miguel para el detalle completo), pero como detalle final, Miguel descubrió que Microsoft mismo utilizó Mono para producir el juego Kinectimals para iOS. ¡Toda una ironía!

Dejo el video (en inglés) del evento de Google Client para que lo disfruten:

lunes, 26 de diciembre de 2011

Raros lenguajes nuevos: Dart (+ video)

Dart

Hace ya varios meses comenzó a circular el rumor de que Google estaba trabajando en un nuevo lenguaje. Entre los rumores se mencionaba un nombre: Dash, y un par de personas, conocidos para los que siguen las novedades en cuanto a lenguajes y máquinas virtuales: Gilad Bracha y Lars Bak.

En la conferencia GOTO, en Aarhus, Dinamarca, durante octubre de este año, se descorrió el velo y se presentó el nuevo lenguaje, con nombre definitivo similar al inicial: DART.

Efectivamente los autores detrás son Bracha y Bak. Bracha se ha autodenominado Teólogo Computacional Emérito, y conocido por ser coautor de la Especificación del Lenguaje Java y creador de los lenguajes StrongTalk (un entorno de Smalltalk, en realidad, creado antes de entrar en Sun) y más recientemente, Newspeak. Lars Bak es un reconocido en máquinas virtuales, habiendo liderado en Sun proyectos como HotSpot y Java ME, el entorno de ejecución de Self y más recientemente V8, el motor de ejecución de JavaScript abierto que forma parte de Google Chrome.

Google mantiene dos proyectos en paralelo respecto a la evolución de JavaScript: por un lado sigue apoyando fuertemente el desarrollo de EcmaScript (el verdadero nombre de JavaScript) para resolver algunos de los problemas de diseño que acarrea a lo largo de los años. Por otro lado, reconociendo que este es un camino que tomará muchísimos años y será complejo implementar algunas soluciones, mantiene también a Dart como una alternativa posible.

Dart es un lenguaje con muchas características conocidas, que no sorprende demasiado, pero con una base muy fuerte en su motor de ejecución, y mantiene la capacidad de ejecutarse nativamente dentro del navegador, algo que todavía no está completamente soportado ni en Chrome, pero si experimentalmente en una versión particular de Chromium (el proyecto abierto) siguiendo instrucciones particulares para compilarla.

Las características principales de Dart como lenguaje son:

  • Tipos estáticos opcionales (si no se declaran son dinámicos)
  • Herencia simple basada en clases con interfaces
  • Genéricos
  • Sintaxis muy similar a JS
  • Interpolación de strings
  • Lambdas
  • Modelo de aislamiento similar a Erlang (cada Isolate es un conceptualmente un proceso sin nada compartido, comunicándose por pase de mensajes, pudiendo correr en paralelo)

Las opciones de ejecución son realmente tres:

  • Compilar de Dart a JavaScript (la única opción que permite generar y ejecutar aplicaciones hoy en día)
  • Ejecutar el código Dart en su propia máquina virtual (aun no soportada realmente en ningún navegador, pero si en las herramientas Dart)
  • Crear una imagen (se trata de una imagen del heap de una aplicación que puede empaquetarse y reactivarse instantáneamente, similar a una imagen de Smalltalk).

Para utilizar Dart es necesario descargar y utilizar un conjunto de herramientas empaquetadas como un plugin de Eclipse, o para probar el lenguaje en un contexto más básico se puede utilizar Dartboard, un pequeño editor en linea con las herramientas detrás, en el servidor. En la imagen debajo pueden ver DartEditor corriendo en mi computadora:

Dart Editor

Para los más interesados, dejo un video y presentación de Gilad Bracha mismo en InfoQ (en inglés). Lamentablemente la gente de InfoQ no permite embeber el video de manera directa, pero es en parte porque ellos brindan una experiencia muy buena al sincronizar el video del presentador junto a las diapositivas en cuadros separados.

martes, 20 de septiembre de 2011

Video: Google Developer Day en Buenos Aires

Buenos Aires, ArgentinaAyer estuve brevemente en el arranque de Google Developer Day en Buenos Aires, que continúa hoy (ya que a pesar del nombre son dos días). Fue bueno, como siempre, encontrar amigos y compartir alguna novedades.

La charla de apertura se transmitió en vivo a través de YouTube y afortunadamente ya está disponible para que disfruten aquí mismo quienes no llegaron a tiempo.

La agenda completa incluye temas como Google TV, Android, Chrome, App Engine, HTML5, oAuth, OpenID, Google+, App Script, YouTube Live Streaming, y otros temas.

Espero que pronto estén disponible el resto de las sesiones y pueda compartirlas.

Les dejo el video de la apertura, de aproximadamente una hora y cuarto de duración. Pueden saltear los primeros minutos de la cuenta regresiva, y queda sólo una hora.

viernes, 9 de septiembre de 2011

¿Cómo funcionan los navegadores?

Mi amigo y compañero de trabajo Charly Páez compartió el otro día este documento que me parece algo fundamental para todo desarrollador hoy día. Está en inglés, pero no podía dejar de compartirlo con ustedes.

How Browsers Work: Behind the Scenes of Modern Web Browsers”, es parte del portal HTML5 Rocks construido por Google, conteniendo introducciones, presentaciones y guías de referencia.

Como se explica en el prefacio, gran parte de este documento surge de la cuidadosa investigación de la desarrolladora israelí Tali Garsiel sobre las características internas y análisis del código de WebKit (Safari y Chrome)  y Gecko (Firefox) los motores de presentación de código abierto que hoy suman aproximadamente un 60% del uso de la web. Aunque Internet Explorer no puede ser analizado de la misma manera, los lineamientos generales de su arquitectura seguramente no difieren fundamentalmente de lo que este documento cubre.

El contenido completo cubre los siguientes procesos, basados en el flujo típico debajo (dejo muchos términos si traducir para evitar confusiones):

  • El motor de rendering
  • Parsing y construcción del DOM (HTML, CSS, Scripts)
  • Construcción del árbol de render
  • Layout (distribución de los elementos)
  • Painting (la aparición real de los elementos en pantalla)
  • Cambios dinámicos
  • Los hilos del motor de rendering
  • Modelo visual de CSS2

Todo comienza con la descripción de alto nivel de la estructura de los navegadores, resumida en el siguiente diagrama:

El trabajo es bastante extenso y detallado, pero nuevamente lo recomiendo muy especialmente. No importa aprender todo ese nivel de detalle, pero leerlo detenidamente nos permite retener al menos algunos conceptos generales que nos ayudarán a comprender más fácilmente situaciones comunes en el desarrollo web.

lunes, 25 de julio de 2011

Google App Engine completó el soporte para Go

La semana pasada el equipo de Google App Engine, la plataforma como servicio para ejecutar aplicaciones en la nube, anunció soporte para Go, uno de esos raros lenguajes nuevos, en este caso generado por el mismo Google, en lugar de surgir del ambiente académico o la comunidad de código abierto.

Esto hace que Go, diseñado para ser un lenguaje de sistema de un nivel apenas superior a C++, eliminando los típicos problemas de manejo de memoria y aportando características específicas para situaciones de alta concurrencia y paralelismo.

Go es un lenguaje “de llaves”, en la tradición familiar de C, pero sin necesidad de puntos y comas, al menos (las lleva pero el compilador se encarga de ponerlas solo). Veamos el clásico Hola, Mundo:

package main

import "fmt"

func main() {
fmt.Println("Hello, 世界")
}

Una de las características más interesantes de Go, y una de las que lo hace especialmente interesante para aplicaciones en la nube, es su implementación de co-rutinas, o funciones que pueden ejecutarse en paralelo, utilizando, casualmente, la sentencia “go”, pero además permite definir “canales” para mantener la comunicación entre procesos. Para los interesados que aún no lo hayan hecho, hay un buen tutorial de Go con muchos ejemplos.


Quienes quieran probar Go en Google App Engine, pueden comenzar con las instrucciones en Google Code.

martes, 19 de abril de 2011

Videos desde el pasado: arquitectura

Toda empresa toma decisiones dolorosas, debatibles o erróneas, pero finalmente tenemos que aceptarlas aunque no nos gusten si están dentro de los términos que aceptamos en su momento.

En estos días, Google anunció que va a eliminar el contenido subido a Google Video (que ahora es solamente un índice), lo que significa que varios millones de videos van a perderse en el tiempo. El 29 de abril (en 10 días más) todo este material se va a ir, pero al menos dejaron la posibilidad de que uno descargue los videos que había subido y los mueva a otro lado.

Lamentablemente lo que se puede descargar no es el video original, sino la versión en formato FLV procesada por Google en su momento (estimo que el original no deben haberlo guardado), así que los que pude recuperar no están en el mejor de los formatos, pero me pareció interesante la oportunidad de compartirlos.

En esta primera tanda comparto tres sesiones mías del año 2007, presentadas dentro de una serie sobre arquitectura de software en el MUG, que di a lo largo de varios meses entre Buenos Aires y Rosario. No todas quedaron registradas, pero estas tres si, y aunque el tiempo se nota, las republico porque en su momento tuvieron buena recepción.

La primer sesión es una introducción al modelo arquitectónico REST (Representational State Transfer), que hoy está sumamente difundido, pero en aquel momento todavía era algo novedoso. Sobre el final menciono un libro de Rails que en esa época todavía no era RESTful por omisión.

Los dos siguientes son parte de una serie de Casos de Arquitectura, que eran charlas en las que analizaba la manera en que estaban construidas algunas aplicaciones fuera de lo común, en particular en cuanto a escalabilidad, que era un tema menos frecuente en ese entonces (antes de la explosión de las redes sociales, por ejemplo). Además de las sesiones sobre Joost y Google Search que publico aquí abajo, recuerdo haber hablado sobre Second Life, YouTube (a meses de haber sido adquirido por Google), EBay y Amazon, entre otros.

El primero de los dos casos, Joost, aún existe pero se convirtió en un sitio web de nicho que perdió la gracia del proyecto original que utilizaba una red peer-to-peer para transmitir video en muy buena calidad con un consumo limitado de ancho de banda.

El segundo caso lo dediqué a Google Search, que a pesar de haber crecido muchísimo, sigue trabajando sobre premisas similares. Muchas de las tecnologías que explico en la sesión, como Bigtable, el Google File System o MapReduce están ahora disponibles como proyectos de código abierto o como parte de Google App Engine.

lunes, 4 de abril de 2011

Page Speed online: una nueva herramienta para medir el rendimiento de sitios web

page speed online

Parte del desarrollo de sitios web de calidad es hacer un análisis correcto de su rendimiento, sobre todo desde temprano, utilizando recomendaciones y técnicas modernas para asegurar un sitio correctamente optimizado. Esto no quiere decir ir en contra de la famosa máxima de Donald Knuth, quien nos ensenó que "la optimización prematura es la causa de todos los males" en programación.

Cualquier sitio web público con una expectativa mínima de tráfico debería responder a una línea base para garantizar una buena experiencia a sus usuarios, y hoy día no necesitamos aplicar técnicas extravagantes o perder mucho tiempo para esto, sino más bien aplicar recursos estándares y sencillos, disponibles en todas las plataformas.

Entre las herramientas para realizar el análisis de rendimiento frecuentemente mencionamos la clásica Firebug (y su plugin YSlow) para Firefox, y Page Speed para Firefox o Chrome. Ambas son excelentes y complementarias, cada una con sus fortalezas, pero ahora Google aporta una alternativa más que puede ser útil en muchas circumstancias: Page Speed online.

A diferencia de las anteriores, en lugar de un plugin, este es un servicio en línea que realiza el mismo tipo de análisis, con lo que podemos ejecutarlo desde cualquier navegador, pero sobre todo puede orientar el análisis sobre navegadores desktop (corriendo en una computadora) como sobre navegadores móviles (sobre todo corriendo en smartphones), para los que incluye algunas reglas específicas como la de eliminar redirecciones en la página inicial que no puedan mantenerse en cache, o reducir la cantidad de Javascript durante la carga de la página. Estas son todas situaciones que no son tan problemáticas en otro ambiente, pero en un teléfono que tiene usualmente un ancho de banda y procesamiento limitados, hacen mucha diferencia.

Veamos un ejemplo. Realicé un análisis para navegadores desktop sobre un sitio popular como Twitter, ingresando la dirección:

page speed Twitter

Y el resultado dio 77 sobre 100 (bastante bueno). El detalle es el siguiente:

Prioridad alta: Estas son reglas que pueden generar mayor impacto en el rendimiento del sitio y que uno debería atacar inicialmente. En el caso de Twitter sólo queda en este nivel la regla: Combinar imágenes como sprites CSS.

Prioridad media: En el siguiente nivel las reglas son: entregar imágenes a escala, optimizar imágenes y minificar Javascript.

Prioridad baja: En este nivel ya hay unos cuantos más. Si quieren pueden ver el informe completo.

Para terminar ejecuto el mismo análisis para la versión móvil de Twitter:

twitter mobile

... y: ¡Oh, sorpresa! me da 100/100. No es de extrañar que Twitter esté muy optimizado para su acceso desde móviles. Así que pruebo con otro servicio que tiene buena tradición en cuando a rendimiento (es donde se empezó a trabajar en estas áreas): http://news.yahoo.com/

El resultado para móviles es de 79/100, que es bastante bueno.

No hay reglas de alta prioridad para atacar, y en las de media, ambas son muy específicas para teléfonos: diferir la interpretación de Javascript y hacer que las redirecciones de la página de inicio puedan mantenerse en cache.

Como siempre, lo importante de estos análisis es leer con atención la información acerca de cada regla, entender de qué se trata y que prácticas tenemos que adoptar de manera permanente para que no vuelva a producirse.

 

miércoles, 23 de marzo de 2011

Navegadores actualizados: lo bueno, lo malo y lo feo

En estos últimos días hubo muchísima actividad alrededor de los navegadores web principales.

Por todos lados resonó el lanzamiento de FireFox 4, y con menos ruido desde la comunidad pero mucha promoción se lanzó también Internet Explorer 9. Por su parte, sin tanto ruido, Google Chrome siguió actualizándose silenciosamente y en mi caso pasó a la versión 11 Beta (quienes no están suscriptos al canal beta deberían estar alrededor de la versión 10.0.648.15).

A continuación algunos detalles, apreciaciones y recursos que me parecen interesantes para desarrolladores:

IE 9

Internet Explorer 9

Esta versión es una imprescindible actualización de Microsoft, mientras hace esfuerzos denodados por eliminar los últimos restos de IE 6, que ya es un problema grave hasta para ellos mismos.

Casualmente, días antes del lanzamiento de IE 9 lanzaron también la campaña http://ie6countdown.com/ que me parece llena de problemas. Este sitio propone incorporar un banner que se activa si el navegador con que se accede al sitio es IE 6, pero en caso que el usuario en cuestión le preste atención y haga clic en el banner, es derivado al sitio de Internet Explorer, donde lo más probable es que termine descargando Explorer 8, no el 9.

He aquí uno de los principales problemas que veo en IE 9: no tiene soporte en Windows XP, un sistema operativo que sigue teniendo un nivel de presencia enorme, y que es el que deben estar utilizando la mayor cantidad de los usuarios que usan aún IE6. El resultado es que muchos de esos usuarios quedarán usando un navegador que todavía no cumple con los estándares modernos.

Fuera de este detalle, IE 9 se puso al día y soporta una buena cantidad de los últimos estándares conocidos como HTML 5. No implementa todos porque Microsoft tomó la decisión de no atacar estándares que no estén a cierto nivel de decisión, con lo que en la práctica hay cosas que otros navegadores soportan y IE9 no, pero el argumento es al menos atendible y la brecha es mucho menor.

IE9 es muy rápido, usa muy bien la aceleración gráfica, y tiene algunas características interesantes en cuanto a su integración con Windows. Claro, sólo corre en Windows, lo que es otra gran diferencia con respecto a los demás.

Para quienes estén interesados, Microsoft Argentina realizará un evento gratuito sobre las novedades, el próximo lunes 28, en sus oficinas de Bouchard 710, 4to piso, en Buenos Aires. Aunque es gratuito, requiere registración. Para más detalles y registro ver el post de Miguel Sáez sobre el evento.

Firefox 4

Firefox 4

Mozilla finalmente liberó la nueva versión de su producto más famoso. Desde el punto de vista de los cambios visibles, en varias áreas comparte con IE9 el acercarse más a algunos principios establecidos por Chrome, como minimizar el espacio que el navegador mismo toma de la pantalla, dejando todo lo posible para el contenido.

También avanza en mayor soporte para los estándares, y aunque la versión acaba de salir, un dato importante para los desarrolladores es que FireBug ya está actualizado para esta versión.

Otro aspecto interesante es que esta va a ser la última entrega de Firefox que se deba descargar e instalar. A partir de ahora, las actualizaciones también seguirán el mecanismo de "goteo" de Chrome, y el navegador se mantendrá actualizado en forma paulatina, sin mayor intervención del usuario, aunque algunas actualizaciones queden a la espera de que el navegador -o el sistema completo- se reinicie.

Chrome

Chrome

Una de las novedades más importantes de Chrome es que cambió el logo/icono, como pueden ver.

Hablando un poco más en serio, los cambios son como siempre incrementales, y en el caso de la versión beta, experimentales. Por ejemplo, ya están probando algunas APIs de voz y usando aceleración gráfica para el soporte 3D en las hojas de estilo.

Más adelante se ve venir que están por quitar Gears de Chrome, ya que esta extensión existía para dar soporte a características que ya se han implementado en HTML5. Sin embargo, muchas opciones de soporte fuera de línea de aplicaciones como GMail, Calendar y Docs lo utilizan, por lo que no sería raro ver que pronto estos productos migren hacia los nuevos estándares.

 

lunes, 28 de febrero de 2011

Mejorando aplicaciones web con Chrome Developer Tools (video)

Google Chrome

Una de las características que el navegador de Google tuvo desde el inicio fue la integración de un buen juego de herramientas para desarrolladores.

Y estas herramientas siguen progresando a lo largo del tiempo, ayudándonos en el desarrollo web (por supuesto sin importar qué navegador usen los usuarios finales). Para quienes quieran aprovechar las últimas características, es recomendable utilizar la versión disponible en el Chrome Beta Channel.

Algunas de las funciones principales incluyen:

  • Edición en vivo del DOM y las plantillas CSS (ideal para retocar sobre el navegador y experimentar hasta ajustar las páginas)
  • Depuración de JavaScript utilizando un depurador gráfico y pudiendo marcar breakpoints, o incluso editar scripts sobre la marcha, agregando sobre el navegador datos de depuración o ayudas.
  • Analizar el tiempo de ejecución de cada función para optimizar el rendimiento.
  • Seguir el flujo y proceso de pintado de las páginas mientras cargan.
  • Explorar el almacenamiento en bases de datos locales de HTML5.

Es interesante saber que estas herramientas están escritas por completo usando JavaScript y CSS, y cualquiera puede revisar el código fuente e incluso postularse para contribuir al proyecto.

Dejo un video corto (4 minutos y medio) en el que un ingeniero de Google demuestra cómo usar estas herramientas. El video está en inglés, pero la explicación es muy clara y ver las herramientas en acción seguramente les permita descubrir algún recurso que todavía no aprovechaban.

lunes, 7 de febrero de 2011

Cómo acelerar nuestras aplicaciones web

High Performance Web Sites

Desde hace ya tiempo la mayoría de las aplicaciones que desarrollamos son aplicaciones web. Incluso el límite entre aplicaciones web y de escritorio es cada vez más difuso, entre nuevas tecnologías basadas en plugins como Flash, Silverlight o Unity, y el incremento de poder del lado de HTML y Javascript, incluyendo también soporte offline y otras características.

Sin embargo, la web, por las maravillas de la diversidad que la hacen fabulosa, también es un océano de calamidades desde el punto de vista del diseño e implementación de las aplicaciones que encontramos en ella.

A esta altura la mayoría de nosotros debería conocer las recomendaciones y herramientas básicas para optimizar los tiempos de respuesta de nuestras aplicaciones, pero nunca está de más repasarlas.

La mayor parte de estas recomendaciones surgen del trabajo de Steve Souders, iniciado cuando era el Chief Performance en Yahoo!, antes de continuar esta labor desde Google, y compilado en dos libros que ya debería considerarse como obligatorios para cualquier desarrollador que tenga que tocar algo en la web:

Even Faster Web Sites

High Performace Web Sites (de 1997) y Even Faster Web Sites (de 2009)

La mayoría de estas reglas pueden verse en detalle en el sitio para desarrolladores de Yahoo, especialmente en la sección de Mejores Prácticas para acelerar un Sitio Web o su equivalente en Google, Mejores prácticas de rendimiento Web.

Dejo un resumen rápido de algunas recomendaciones, para que se den una idea antes de zambullirse en la lectura de todo ese material.

Minimizar peticiones HTTP

  • Combinar archivos es una manera de reducir peticiones, por ejemplo, unificando las hojas de estilo y scripts
  • Utilizar Sprites CSS para combinar muchas imagenes en una sola y descomponerla en la página

Utilizar redes de distribución de contenido (CDNs)

Esto no aplica a cualquier sitio, porque implica un costo, pero cada vez aparecen más alternativas económicas o embebidas directamente sobre alguna plataforma más amplia.

Agregar expiración o control de cache en la cabecera

Tanto en contenido estático como dinámico, manejando apropiadamente estos mecanismos podemos lograr que el browser descargue una única vez los recursos que no varían. Esto es particularmente efectivo en cosas como imágenes, hojas de estilo, scripts, etc, pero también se puede lograr mantener la mayor parte del HMTL utilizando mecanismos de fragmentación para separar el contenido que realmente varía.

Comprimir componentes con Gzip

Esta es una de las recomendaciones que es casi gratuita. La mayoría de los navegadores modernos soportan este tipo de compresión que es estándar, lo mismo que casi todos los servidores web. Sólo implica indicar que debe ser utilizada al hacer las peticiones.

Ubicar las hojas de estilo arriba de la página

Ubicar los estilos en la cabecera del HTML hace que la carga de la página se perciba más rápida porque permite que suceda progresivamente.

Ubicar los scripts al final de la página

La descarga de los scripts genera muchas veces un freno a la descarga en paralelo de otros elementos, porque supo que parte del código puede estar escribiendo parte del contenido de la página. Hay varias técnicas para evitar el problema y mejorar el rendimiento general.

Evitar expresiones CSS

Estas expresiones permiten asignar valores dinámicos a propiedades de los estilos, pero esta es una operación peligrosa y lenta, por lo que se la convirtió en obsoleta.

Los scripts y hojas de estilo deberían ser externos

Independizar estos recursos mejorar usualmente el rendimiento porque además de poder paralelizarse la descarga, estos son recursos ideales para permanecer mucho tiempo en la cache del navegador.

Reducir la cantidad de búsquedas en los DNS

Esto es algo en lo que hay que mantener un balance. Las búsquedas en los servidores de nombres son mantenidos en cache por los navegadores por varios minutos, porque son una operación relativamente costosa. De todas maneras, cierta distribución de recursos en diferentes dominios también ayuda a paralelizar las descargas, ya que los navegadores tienen un límite de cantidad de descargas en paralelo por cada dominio.

Minificar JavaScript y hojas de estilo

Esta práctica implica compactar en ambos casos la cantidad de caracteres en uso para todos los recursos internos como estilos, variables y nombres de funciones, al igual que reducir la cantidad de espacios opcionales e indentación. Esto hace que el resultado parezca críptico, pero puede resolverse en una etapa posterior al desarrollo, como parte del despliegue (utilizando JSMin y YUI Compressor, por ejemplo), de modo que dentro del ciclo de vida de un proyecto nadie tenga que leer las versiones minificadas.

Evitar redirecciones

Aunque este es un recurso útil en ciertos casos, su abuso genera demoras y una experiencia poco prolija, que es difícil de optimizar.

Remover scripts duplicados

Aunque parezca obvio, la cantidad de sitios que incluyen mas de una vez el mismo script en una página es enorme. En parte, si se trabaja fuertemente en la unificación de los scripts, las posibilidades de que esto suceda disminuyen inmediatamente.

Configurar ETags

A pesar de que los ETags son un mecanismo para evitar transferir recursos ya existentes, implementaciones divergentes de este estándar en distintos servidores terminan generando que algunos recursos se descarguen siempre, sin importar si ya están actualizados en el navegador. Es importante revisar la manera en que funcionan y estar seguro que lo hacen correctamente.

Hacer que las llamadas AJAX utilicen la cache

Aunque esta técnica de pedir datos de manera asincrónica sin tener que reenviar toda la página está pensada para minimizar el tráfico, es importante aplicar muchas de las recomendaciones anteriores a estos casos también. Esto implica hacer que las respuestas generalmente dinámicas de estos servicios utilicen los mismos mecanismos para evitar el reenvío de respuestas que ya llegaron antes al navegador y cuyo contenido no cambió.

 

¿Cómo controlar y validar estas reglas?

Aunque la lista pueda amedrentarnos en principio, ya hay varias herramientas disponibles para ayudarnos en este camino, como la clásica YSlow (un plugin de FireBug, que a su vez es un plugin para FireFox). Va como muestra una captura del análisis de YSlow en este blog (para que vean que todos cometemos pecados).

Analisis de YSlow

Google, por su parte, tiene también una extensión similar pero con algunas características particulares, llamada PageSpeed, producto de la mudanza de Souders. Notablemente esta extensión también es para FireBug, por lo que corre en FireFox, no en Chrome.

Finalmente, Google ha publicado también el módulo mod_pagespeed para Apache, que aplica muchas de las reglas automáticamente, al preprocesar scripts y hojas de estilo, unificando y minificándolas, optimizando imagenes, etc.

Es interesante ver que GoDaddy, el principal registrador de domininos y una de las principales empresas de hosting en el mundo, ha empezado a activar este módulo en todos sus servidores Apache, produciendo mejoras significativas en muchísimos de sus cliente de manera casi mágica.

 

jueves, 6 de enero de 2011

Videos: Previews de Surface 2.0 y Android 3.0 (Honeycomb)

CES 2011

Durante la CES (la conferencia anual de electrónica para consumidores) que arrancó ayer, hubo unos cuantos anuncios ya, y algunas novedades ya dan vueltas por la red.

Microsoft pesentó la segunda versión de su dispositivo Surface, que ahora es muchísimo más fino ya que no usa más cámaras internas para capturar lo se apoya sobre la pantalla, sino que usa una tecnología en la que cada pixel es un sensor independiente. Esto permite usarlo no sólo como mesa, sino también como kiosko, más parecido a un televisor.

Google hara varios anuncios también, y ya tenemos al menos un video que muestra algunas características de la próxima versión de Android, que notarán orientado a mejorar la experiencia en tabletas además de teléfonos. Es interesante notar que algunas cosas como Maps en 3D y StreetView ya están disponibles hoy, aunque no con la misma velocidad que en el dispositivo del video.

Les dejo los videos de Surface y Android para que disfruten e imaginen aplicaciones:

 

viernes, 10 de diciembre de 2010

Finalmente está aquí: Chrome Web Store

Chrome Web Store

Como se venía anunciando desde hace tiempo, esta semana abrió al público la Chrome Web Store.

La idea de esta tienda en línea es brindar el mismo tipo de experiencia de búsqueda de aplicaciones con calificaciones y comentarios de usuarios, categorías, descripciones, y opciones pagas o gratuitas que los usuarios de teléfonos inteligentes disfrutan desde el éxito del AppStore del iPhone, y que fue replicado en Android, Windows Phone 7, la iPad y demás.

Hay bastante discusión en línea acerca de que esta tienda no es más que maquillaje sobre el concepto de links y favoritos, pero veamos un poco sus características:

Lo primero que notará quien la acceda desde un navegador que no sea Chrome será que las aplicaciones sólo funcionan en ese browser. La imagen a continuación está capturada desde mi Firefox.

Web Store Home

¿Porqué sólo funciona en Chrome? En principio porque las aplicaciones pueden ser de varios tipos.

El nivel más básico puede ser un sitio web tradicional al que se le agrega sólo algo de metadata que usa la tienda para identificarla. Pero también puede ser una extensión para Chrome o un tipo de aplicación web más específico que puede descargarse y correr incluso offline dentro del sandbox de Chrome. Estos dos tipos de aplicaciones pueden utilizar además el API de Chrome para brindar funcionalidad específica más integrada al browser mismo.

Desde el punto de vista de nosotros como desarrolladores, lo más importante es el Developer Dashboard, que permite publicar cualquiera de estos tipos de aplicaciones, sin restricciones específicas, ya que Google ha decidido dejar la tarea de evaluar las aplicaciones a los usuarios mismos. Para poder publicar cualquier cosa, debe realizarse un pago por única vez de 5 dólares, más orientado a verificar la identidad asociada a la cuenta utilizada que a otra cosa.

Más que ninguna otra cosa, este es un nuevo mecanismo para dar a conocer aplicaciones y sigue empujando el mercado de empresas pequeñas de desarrollo que pueden alcanzar una alcance global con facilidad.

El principal problema que veo a todo esto es que crea un nuevo silo en lugar de ser algo abierto, pero es un experimento interesante.

martes, 7 de diciembre de 2010

Android 2.3 (Gingerbread) recién salido del horno

Siguiendo la tradición de ponerle nombres de cosas dulces a las versiones de sus sistema operativo para dispositivos, Google lanzó Android 2.3, conocido como Gingerbread, y su correspondiente Kit de Desarrollo.

Como curiosidad, estos son los nombres de las versiones anteriores:

1.51.62.0/2.12.22.3
CupcakeDonutEclairFroyoGingerbread

Cupcake

Donut

Eclair

Froyo

Gingerbread

Las mejoras principales de esta versión se enfocan en:
  • Mejoras para desarrollo de juegos Principalmente a través de mejoras en el tiempo de respuesta gracias a retoques en el garbage collector y manejo de eventos, y exponiendo más APIs nativas que permiten acceder a bajo nivel las entradas y sensores (incluyendo giróscopos), EGL/OpenGL ES, OpenSL ES, etc.
  • Más riqueza multimedia La plataforma soporta ahora estándares de video abiertos como VP8 / WebM, audio y voz AAC y  ARM-wideband, y agrega efectos como reverb, ecualización, virtualización de audífonos y mejora de bajos.
  • Más formas de comunicación La plataforma soporta múltiples cámaras, típicamente para una frontal utilizada en video chats, soporte de llamadas via internet via SIP/VOIP,  y NFC (Near Field Communications) para permitir que los dispositivos se comuniquen con otros dentro de un rango de proximidad de unos 10 centímetros.

Aquí dejo el video promocional:

Y la liberación de la nueva versión se cristaliza con la aparición en conjunto de un primer dispositivo que trae esta versión de fábrica, el Nexus S, que Google desarrolló en conjunto con Samsung. Dejo también el video promocional para que se entretengan:

 

martes, 2 de noviembre de 2010

Google DevFest en Buenos Aires (Día 1)

Tim Bray habla de Android

En el coqueto auditorio de la Universidad Católica Argentina arrancó el Google DevFest de este año.

El primer día estuvo dedicado exclusivamente a Android. Por la mañana hubo un evento previo al que no asistí, destinado a que los participantes instalaran el SDK y desarrollaran su primer aplicación Android.

Los comentarios fueron variados, pero al parecer sirvió como una primer experiencia, aunque algunos decían que se perdió mucho tiempo instalando (algo que se suponía que los asistentes debían hacer previamente).

Por la tarde, el evento principal estuvo compuesto por cuatro charlas:

Un vistazo a Android SDK y lo nuevo en Froyo, que debía presentar Billy Rutledge pero presentó Tim Bray, como puede verse en la foto.

Bray es un gran presentador, aunque me pareció un desperdicio dando esta introducción.

Construcción de Aplicaciones de Alto Desempeño fue la siguiente charla de Bray, que mantuvo el nivel básico, y era en realidad como hacer aplicaciones que no tengan pobre desempeño. Mucho foco en cosas como no utilizar reflection, no acceder el file system o -peor aún- la red desde el thread de la interfaz de usuario, y otros temas que los desarrolladores profesionales deberían saber a esta altura. Como temas interesantes mostró algunas herramientas de profiling como TraceView e hizo foco en el clásico "no suponer nada; medir y corregir".

Continuó Fred Chung con Adaptación al Hardware y Locale, una sesión de 45 minutos explicando temas muy básicos como la relación de puntos por pulgada de los dispositivos, como usar wrappers para soportar diferentes versiones del SDK, o como usar archivos de recursos. Confirmó mi apreciación de que el evento se dirige a un nivel muy básico de desarrollador.

Cerró Tim Bray (el dueño de la tarde) con la mejor sesión a mi criterio, sobre Mejores Prácticas para el diseño de IU en Android, en la que recorrió tips realistas sobre diseño de interfaz, bastante genéricos pero útiles, y con detalles específicos de la plataforma. Muy interesante la mención a utilizar Analytics for Mobile para medir qué funcionalidad usan los usuarios en la práctica, y cómo. Y un buen consejo con ejemplo incluido fue el de tener diseñadores profesionales (de interacción, agregaría yo, no gráficos solamente) en el equipo de desarrollo, algo que suele marcar la diferencia con una aplicación que se populariza en el Market y las que no lo hacen.