Clara Rivera

El jueves celebramos el primer Open Pizza Night, un encuentro informal en torno a unas cuantas pizzas para presentar y probar productos de Google. En este caso aprovechamos para programar con las nuevas APIs de YouTube. Era la primera vez que hacíamos algo así en la oficina y, antes de nada, quiero dar las gracias desde aquí a todos los que mostraron su interés por el evento. Nos habría gustado dar cabida a todas las solicitudes, pero nos vimos desbordados y hubo muchos programadores que no pudieron asistir. ¡Esperamos contar con todos vosotros la próxima vez!

Sabemos que no es lo mismo, pero para que os hagáis una idea de qué ocurrió, aquí tenéis la presentación sobre las novedades y un ejercicio del taller.



Clara Rivera

El jueves celebramos el primer Open Pizza Night, un encuentro informal en torno a unas cuantas pizzas para presentar y probar productos de Google. En este caso aprovechamos para programar con las nuevas APIs de YouTube. Era la primera vez que hacíamos algo así en la oficina y, antes de nada, quiero dar las gracias desde aquí a todos los que mostraron su interés por el evento. Nos habría gustado dar cabida a todas las solicitudes, pero nos vimos desbordados y hubo muchos programadores que no pudieron asistir. ¡Esperamos contar con todos vosotros la próxima vez!

Sabemos que no es lo mismo, pero para que os hagáis una idea de qué ocurrió, aquí tenéis la presentación sobre las novedades y un ejercicio del taller.



Hubo aplicaciones muy chulas: dos grupos coincidieron en crear una aplicación para añadir subtítulos a los vídeos, y otro grupo creó una aplicación para votar el "momento álgido" de un vídeo y que además generaba un gráfico. Y todo esto, entre pizza y pizza.

Por último, hubo participantes voluntarios que presentaron sus aplicaciones. Rubén nos presentó Jisko, sistema de microblogging made in Spain y recién salido del horno, Raúl presentó una prueba de concepto de un servicio de microblogging por vídeo que permite grabar y subir vídeos a YouTube directamente, Alberto presentó Dilandau, que empezó como proyecto de fin de carrera, para buscar música en la red, y Dani nos presentó las últimas novedades de la integración del API de YouTube en Tuenti. ¡Muchas gracias a todos!

Os dejo unas fotos, pero podéis verlas todas en el álbum (¡Gracias, Lucía, por mandarnos tus fotos! Las hemos incluido en el álbum.)

El principio


Con la pizza


Las presentaciones de los participantes


Esperamos que lo pasáseis por lo menos igual de bien que nosotros, ¡que fue mucho! Ya estamos deseando volver a organizar otra noche de pizza y código. Por último, no olvidéis enviarnos vuestros comentarios al blog y vuestras aplicaciones utilizando las APIs de YouTube a programacongoogle@google.com.

Joaquín Cuenca

Al principio fue Apache, con un modo de funcionamiento extremadamente robusto. Cada petición se sirve en un proceso hijo distinto. Si algo va mal, el proceso hijo se colgaría, pero no afectaría en absoluto al resto de peticiones servidas por los otros procesos. Método lento, ya que crear un nuevo proceso es lento, pero seguro. Para mejorar el rendimiento se suele usar un "pool" (grupo) de procesos latentes, para no tener que crear un nuevo proceso con cada petición. Así nos ahorramos la creación de un nuevo proceso por petición.
Joaquín Cuenca

Al principio fue Apache, con un modo de funcionamiento extremadamente robusto. Cada petición se sirve en un proceso hijo distinto. Si algo va mal, el proceso hijo se colgaría, pero no afectaría en absoluto al resto de peticiones servidas por los otros procesos. Método lento, ya que crear un nuevo proceso es lento, pero seguro. Para mejorar el rendimiento se suele usar un "pool" (grupo) de procesos latentes, para no tener que crear un nuevo proceso con cada petición. Así nos ahorramos la creación de un nuevo proceso por petición.

Si queremos servir páginas web dinámicas y usamos Apache tenemos principalmente dos posibilidades, usar un "pool" de procesos PHP, qué comunicarán con Apache usando FastCGI, o usar ejecutar PHP directamente desde Apache con mod_php (en lugar de PHP/fastCGI podemos usar Python/SCGI o cualquier otro lenguaje). En el segundo caso, la comunicación entre Apache y el intérprete será más rápida ya que no necesita una comunicación entre procesos (Apache - PHP) por cada petición. Para servir una petición, Apache comunicará con uno de sus procesos libres del pool, y si es una petición dinámica y ese proceso aún no ha cargado mod_php, lo cargará y ejecutará el script correspondiente.

El numero máximo de recursos por segundo que podremos servir antes de agotar la memoría será:

nb_procesos_max = mem_total / mem_proc
recursos_seg = nb_procesos_max / seg_recurso

Donde mem_proc es la memoría que ocupa cada proceso Apache y seg_recurso es el tiempo medio que tardamos en servir un recurso.

Por ejemplo, si tenemos 2 GB de memoria, cada proceso consume 20 MB, y de media tardamos 0.1 segundos en servir una petición, podremos servir un máximo de 2000 / (20 * 0.1) = 1000 peticiones por segundo. Con este modelo, si queremos activar KeepAlives (ver el artículo sobre cómo acelerar la descarga de páginas web) durante 10 segundos, tendremos un límite de 2000 / (20 * 10) = 20 peticiones por segundo. ¡Hemos dividido por 100 nuestro máximo!

Para poder activar KeepAlives sin matar nuestro servidor, o simplemente si queremos consumir menos memoria, tenemos que cambiar de modelo. Sabemos que la mayoría de recursos son simples ficheros estáticos (js, css, png, jpg, etc.). No necesitamos un intérprete PHP para servirlos. De hecho, es tan sencillo que podemos hacerlo directamente desde el proceso principal del servidor web, sin necesidad de usar un proceso secundario ya que la posibilidad de que el proceso se cuelgue haciendo algo tan simple es prácticamente nula. Apache (<= 2.1) no puede funcionar en este modo, y tendremos que usar otro servidor Web, como lighttpd, nginx o cherokee.

Para los recursos dinámicos, podemos mantener un pool de procesos PHP y comunicar con ellos usando fastCGI, o simplemente seguir usando Apache y comunicar con Apache por HTTP (ideal para una migración rápida, ya que podemos seguir usando la configuración previa). La comunicacion entre servidor y PHP será algo más lenta, pero como ventaja desacoplamos el tiempo de vida de la conexión TCP con el del proceso PHP. Lo único que hay que hacer es pedirle a Apache que escuche en otro puerto (Listen 8080) y pedirle al servidor de recursos estáticos que actue de reverse proxy hacia localhost:8080 para todas las peticiones dinámicas.

La mayoría de servidores que permiten este modo de funcionamiento, permiten también usar un pool de procesos para servir los recursos estáticos, pero esta vez un pool pequeño y fijo (por ejemplo de 4 procesos). De este modo podemos aprovechar varios procesadores o un procesador multicore, y paralelizar las peticiones en caso de que alguna llamada al sistema bloquee (en teoría todas las llamadas que se usan son asíncronas, en la práctica a veces bloquean).

Clara Rivera

¡El Summer of Code 2008 está en marcha! El Summer of Code es el programa de prácticas remuneradas de Google. En los tres años que lleva en funcionamiento han participado más de 1500 estudiantes y 2000 mentores de 90 países diferentes, todos por amor al código. Esperamos que este año tengamos muchos más.
Clara Rivera

¡El Summer of Code 2008 está en marcha! El Summer of Code es el programa de prácticas remuneradas de Google. En los tres años que lleva en funcionamiento han participado más de 1500 estudiantes y 2000 mentores de 90 países diferentes, todos por amor al código. Esperamos que este año tengamos muchos más.

En esta edición, todas las organizaciones mentoras que participan han incluido información adicional para sus futuros estudiantes, como por ejemplo una muestra con ideas de proyectos. Los estudiantes interesados en participar pueden enviar sus solicitudes a partir del próximo lunes 24 de Marzo de 2008, así que aprovechad las vacaciones de Semana Santa para conocer mejor las organizaciones participantes.

También de interés para profesores y estudiantes de informática: el verano pasado lanzamos un sitio dirigido a ellos para que se familiarizasen con la tecnología de Google e Internet en general. Ahora lo hemos rediseñado y le hemos dado un nombre nuevo: Google Code University.

Google Code University es un respositorio cada vez mayor de material educativo de informática, que incluye tutoriales, diapositivas y vídeos. Desde su lanzamiento hemos añadido mucho contenido nuevo, por ejemplo, material creado por la Universidad de Washington junto con nosotros sobre clusters a gran escala. Recientemente hemos añadido tutoriales de MySQL y Subversion. Y también hay una serie de clases de un curso de introducción a la programación web impartido en la Universidad de Washington. Google Code University sigue creciendo y en los meses siguientes añadiremos más contenido.

Por último, y lo que es más importante, la mayor parte de los cursos están bajo licencia Creative Commons, así que animamos a profesores y alumnos a que los reutilicen y los mejoren. Si tenéis preguntas o materiales educativos que os gustaría compartir, podéis visitar el Foro (en inglés) o enviarnos un email.




Steph Liu

¿Alguna vez has querido estar en el vertiginoso mundo del vídeo online? ¡Ahora es un buen momento! Acabamos de añadir la posibilidad de autenticación, subida de vídeos y escritura de datos al API de datos de YouTube que lanzamos en otoño. También hoy lanzamos en primicia unas nuevas APIs para el reproductor y otras herramientas.

Steph Liu

¿Alguna vez has querido estar en el vertiginoso mundo del vídeo online? ¡Ahora es un buen momento! Acabamos de añadir la posibilidad de autenticación, subida de vídeos y escritura de datos al API de datos de YouTube que lanzamos en otoño. También hoy lanzamos en primicia unas nuevas APIs para el reproductor y otras herramientas.


De este modo, si tienes un sitio web dedicado a los amantes del mundo de la iguana, por ejemplo, tus usuarios podrán subir vídeos de JubJub a su cuenta de YouTube, comentarlos, crear listas de reproducción sobre iguanas, y más. Y todo desde la comunidad de tu sitio web. Con las APIs del reproductor y el reproductor sin cromo alrededor, puedes personalizarlo totalmente y darle la apariencia de tu sitio web (un tema verde, botones en forma de escamas de iguana, etc.).


Si con tanta emoción no se te ocurre qué hacer ahora, puedes leer los detalles en el blog del API de YouTube (en inglés), ver el vídeo sobre las novedades del API (en YouTube, ¿dónde si no?), repasar la documentación o también puedes apuntarte al foro donde podrás hacer cualquier pregunta que te surja. Estate atento, porque pronto iremos publicando más información.



Javier Arias

No habían pasado ni 24 horas desde el anuncio del lanzamiento de la Google Contacts Data API cuando ya habíamos recibido en nuestra dirección de correo ( programacongoogle@google.com ...
Javier Arias

No habían pasado ni 24 horas desde el anuncio del lanzamiento de la Google Contacts Data API cuando ya habíamos recibido en nuestra dirección de correo (programacongoogle@google.com) el primer ejemplo de aplicación de esta API.

Miguel Cuesta, que lleva el blog google.dirson.com, nos ha enviado el link al post en su blog en el que se hace eco del anuncio de esta nueva API y a la vez incluye un primer ejemplo de uso.

La verdad es que el ejemplo nos ha encantado. No sólo muestra un sencillo caso de uso de Google Contacts Data API (cómo obtener una lista de contactos) sino que también se fija en el uso del protocolo AuthSub que permite a los desarrolladores implementar aplicaciones que acceden a la información en las cuentas de usuario de Google sin necesidad de pedirle al usuario que revele su nombre de usuario y password. Sencillo y didáctico, ¿qué más se puede pedir?

Javier Arias

He de confesaros que estoy especialmente contento de poder anunciaros que hemos lanzado un API para la gestión de contactos. Podéis ver el anuncio original en el blog de las APIs de datos.
Javier Arias

He de confesaros que estoy especialmente contento de poder anunciaros que hemos lanzado un API para la gestión de contactos. Podéis ver el anuncio original en el blog de las APIs de datos.

Y digo que estoy especialmente contento porque hacía mucho tiempo que había echado de menos un API que permitiese el acceso a la lista de contactos de un usuario, lista de contactos que, como sabéis, es compartida entre aplicaciones de Google como Gmail, Google Reader y Google Calendar, entre otras.

El Google Contacts Data API permite a los programadores crear, editar, leer y borrar contactos usando una interfaz Google Data API. También permite sincronizaciones incrementales con el soporte de parámetros "updated-min" y "showdeleted". En la documentación podéis encontrar todas las opciones disponibles.

Son muchas y muy interesantes las aplicaciones que pueden usar la funcionalidad que aporta esta API y ofrecer a los usuarios la ventaja de reutilizar la información de sus contactos. Tengo mucha curiosidad por ver cuál es la primera aplicación basada en esta API que nos enviáis a programacongoogle@google.com: aquí la comentaremos.

Chris Prince

Hoy es un gran día para el desarrollo de aplicaciones para móviles, porque coincide con el lanzamiento de Google Gears para dispositivos móviles. Por el momento, Gears está disponible para Internet Explorer en Windows Mobile 5 y 6.

La situación de la programación para móviles hoy en día no es muy halagüeña: generalmente hay que escribir código nativo y probarlo con diferentes SDKs, con cinco compiladores diferentes. Es una tarea agotadora, que explica por qué tan pocos programadores se dedican a crear aplicaciones para móviles.

Las aplicaciones web son una forma evidente de llevar diferentes funcionalidades a dispositivos móviles. Simplemente hay que escribir la aplicación una vez. Así que, ¿por qué no se ha adoptado más este enfoque? Pues, sencillamente, porque los navegadores de móviles no pueden hacer muchas de las cosas que quieres que hagan las aplicaciones.

Añade Google Gears. El objetivo de Gears es aumentar la capacidad de los navegadores web. Resulta evidente que los navegadores de dispositivos móviles podrían beneficiarse tanto como los de ordenador y así, añadiendo prestaciones a los navegadores móviles, es posible desplegar un número cada vez mayor de aplicaciones móviles, como sucede con las aplicaciones web.

Y aún hay más: tenemos pensado mantener el API de Gears consistente para todas las plataformas. Así que, mientras que aunque tengas que tener en cuenta diferencias de navegador (como tamaños de pantalla y las típicas triquiñuelas con el DOM), el resto de tu aplicación "funcionará" en los diferentes sistemas de los usuarios. No tendrás que preocuparte de si tu aplicación se está ejecutando en un dispositivo móvil o en un ordenador.

Estamos todos muy emocionados con el potencial que encierra este lanzamiento. Esperamos que las aplicaciones móviles creadas con Google Gears den pie a una nueva tendencia en el desarrollo de aplicaciones para móviles.

Para más información, puedes visitar la web y, como siempre, hacernos llegar vuestros comentarios y vuestro feedback a programacongoogle@google.com.


Chris Prince

Hoy es un gran día para el desarrollo de aplicaciones para móviles, porque coincide con el lanzamiento de Google Gears para dispositivos móviles. Por el momento, Gears está disponible para Internet Explorer en Windows Mobile 5 y 6.

La situación de la programación para móviles hoy en día no es muy halagüeña: generalmente hay que escribir código nativo y probarlo con diferentes SDKs, con cinco compiladores diferentes. Es una tarea agotadora, que explica por qué tan pocos programadores se dedican a crear aplicaciones para móviles.

Las aplicaciones web son una forma evidente de llevar diferentes funcionalidades a dispositivos móviles. Simplemente hay que escribir la aplicación una vez. Así que, ¿por qué no se ha adoptado más este enfoque? Pues, sencillamente, porque los navegadores de móviles no pueden hacer muchas de las cosas que quieres que hagan las aplicaciones.

Añade Google Gears. El objetivo de Gears es aumentar la capacidad de los navegadores web. Resulta evidente que los navegadores de dispositivos móviles podrían beneficiarse tanto como los de ordenador y así, añadiendo prestaciones a los navegadores móviles, es posible desplegar un número cada vez mayor de aplicaciones móviles, como sucede con las aplicaciones web.

Y aún hay más: tenemos pensado mantener el API de Gears consistente para todas las plataformas. Así que, mientras que aunque tengas que tener en cuenta diferencias de navegador (como tamaños de pantalla y las típicas triquiñuelas con el DOM), el resto de tu aplicación "funcionará" en los diferentes sistemas de los usuarios. No tendrás que preocuparte de si tu aplicación se está ejecutando en un dispositivo móvil o en un ordenador.

Estamos todos muy emocionados con el potencial que encierra este lanzamiento. Esperamos que las aplicaciones móviles creadas con Google Gears den pie a una nueva tendencia en el desarrollo de aplicaciones para móviles.

Para más información, puedes visitar la web y, como siempre, hacernos llegar vuestros comentarios y vuestro feedback a programacongoogle@google.com.